[Xen-devel] [libvirt bisection] complete build-armhf-libvirt
branch xen-unstable xen branch xen-unstable job build-armhf-libvirt test libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: libvirt git://libvirt.org/libvirt.git Bug introduced: 9f7a559a6d1ab4103de238d59910baefa7b425ff Bug not present: 0e4972fe48aeaade393daf089013092a2ecde4b3 commit 9f7a559a6d1ab4103de238d59910baefa7b425ff Author: Tomas Meszaros e...@tty.sk Date: Mon Aug 10 21:59:14 2015 +0200 Introduce virDomainRename API Also, among with this new API new ACL that restricts rename capability is invented too. Signed-off-by: Tomas Meszaros e...@tty.sk Signed-off-by: Michal Privoznik mpriv...@redhat.com For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-armhf-libvirt.libvirt-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 60708 fail [host=arndale-lakeside] / 60681 ok. Failure / basis pass flights: 60708 / 60681 Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest 834c5720e4434f0bcc807bb1cf20855af63e24a3 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 Basis pass 1b08cc170a84077afd4d15f4639a9a2cf398e9a2 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 Generating revisions with ./adhoc-revtuple-generator git://libvirt.org/libvirt.git#1b08cc170a84077afd4d15f4639a9a2cf398e9a2-834c5720e4434f0bcc807bb1cf20855af63e24a3 git://git.sv.gnu.org/gnulib.git#f39477dba778e99392948dd3dd19ec0d46aee932-f39477dba778e99392948dd3dd19ec0d46aee932 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa-bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa git://xenbits.xen.org/xen.git#201eac83831d94ba2e9a63a7eed4c128633fafb1-201eac83831d94ba2e9a63a7eed4c128633fafb1 + exec + sh -xe + cd /home/osstest/repos/libvirt + git remote set-url origin git://cache:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* From git://cache:9419/git://libvirt.org/libvirt 2b3fb38..0ace4d9 master - origin/master + exec + sh -xe + cd /home/osstest/repos/libvirt + git remote set-url origin git://cache:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* Loaded 1001 nodes in revision graph Searching for test results: 60681 pass 1b08cc170a84077afd4d15f4639a9a2cf398e9a2 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60708 fail 834c5720e4434f0bcc807bb1cf20855af63e24a3 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60769 fail 9f7a559a6d1ab4103de238d59910baefa7b425ff f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60754 pass 1b08cc170a84077afd4d15f4639a9a2cf398e9a2 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60756 fail 834c5720e4434f0bcc807bb1cf20855af63e24a3 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60757 pass 151ba022939dad1e562c4156cb62e7a3ade6a7f5 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60758 fail ff486e0d29a7c08e7131447ca3c878ed791def4e f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60760 pass 0e4972fe48aeaade393daf089013092a2ecde4b3 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60763 fail 9f7a559a6d1ab4103de238d59910baefa7b425ff f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60764 pass 0e4972fe48aeaade393daf089013092a2ecde4b3 f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60765 fail 9f7a559a6d1ab4103de238d59910baefa7b425ff f39477dba778e99392948dd3dd19ec0d46aee932 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60767 pass 0e4972fe48aeaade393daf089013092a2ecde4b3 f39477dba778e99392948dd3dd19ec0d46aee932
[Xen-devel] [xen-unstable test] 60711: regressions - FAIL
flight 60711 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/60711/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat fail REGR. vs. 60683 test-armhf-armhf-xl-raw 5 xen-install fail REGR. vs. 60683 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail like 60662 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 60683 test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 60683 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 60683 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 60683 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 guest-start.2fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen 672101b54269d7a69c2ccaa345ea396dcca63238 baseline version: xen 145a8004a7d659668d5a3b0ad9868d7678b24822 Last test of basis60683 2015-08-13 02:26:04 Z5 days Testing same since60711 2015-08-15 14:19:51 Z2 days1 attempts People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Boris Ostrovsky boris.ostrov...@oracle.com Dave Scott dave.sc...@eu.citrix.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2
El 11/08/15 a les 16.19, Ian Campbell ha escrit: On Fri, 2015-08-07 at 10:11 +0800, Shannon Zhao wrote: This document is going to explain the design details of Xen booting with ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are welcome. Some small subsets of this seem like they might overlap with what will be required for PVH on x86 (a new x86 guest mode not dissimilar to the sole ARM guest mode). If so then it would be preferable IMHO if PVH x86 could use the same interfaces. I've trimmed the quotes to just those bits and CCd some of the PVH people (Boris and Roger[0]) in case they have any thoughts. Actually, having done the trimming there is only one such bit: [...] 4. Map MMIO regions --- Register a bus_notifier for platform and amba bus in Linux. Add a new XENMAPSPACE XENMAPSPACE_dev_mmio. Within the register, check if the device is newly added, then call hypercall XENMEM_add_to_physmap to map the mmio regions. Ian. [0] Roger is away for a week or so, but I'm expect feedback to be of the we could use one extra field type rather than this needs to be done some totally different way for x86/PVH (in which case we wouldn't want to share the interface anyway I suppose) so need to block on awaiting that feedback. This looks right to me. AFAICT this new memory space (XENMAPSPACE_dev_mmio) will only be available to the hardware domain on x86. I expect that for DomUs the toolstack will already map the appropriate MMIO regions when creating the domain if there are pass-through devices assigned, not sure if that's also the plan on ARM. IMHO this document should also list the usage of the hypercall parameters: - space: XENMAPSPACE_dev_mmio. - idxs: native physical addresses. - gpfns: guest physical addresses where the mapping should appear. This is quite obvious but I think it's worth spelling it out. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
Saturday, August 15, 2015, 12:39:25 AM, you wrote: On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote: On 2015-08-13 00:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is breaking things (have to test if a revert helps) i get this in some guests: Yes, this was fixed by : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af Hi Eric, With that patch i had a crash again this night, see below. -- Sander [177459.188808] general protection fault: [#1] SMP [177459.199746] Modules linked in: [177459.210540] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150815-linus-doflr-net+ #1 [177459.221441] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [177459.232247] task: 8221a580 ti: 8220 task.ti: 8220 [177459.242931] RIP: e030:[8110eb58] [8110eb58] detach_if_pending+0x18/0x80 [177459.253503] RSP: e02b:88005f6039d8 EFLAGS: 00010086 [177459.264051] RAX: 8800584d6580 RBX: 880004901420 RCX: dead00200200 [177459.274599] RDX: RSI: 88005f60e5c0 RDI: 880004901420 [177459.285122] RBP: 88005f6039d8 R08: 0001 R09: [177459.295286] R10: 0003 R11: 880004901394 R12: 0003 [177459.305388] R13: 00010ae47040 R14: 07b98a00 R15: 88005f60e5c0 [177459.315345] FS: 7f51317ec700() GS:88005f60() knlGS: [177459.325340] CS: e033 DS: ES: CR0: 8005003b [177459.335217] CR2: 010f8000 CR3: 2a154000 CR4: 0660 [177459.345129] Stack: [177459.354783] 88005f603a28 8110ee7f 810fb261 0200 [177459.364505] 0003 880004901380 0003 8800567d0d00 [177459.374064] 07b98a00 88005f603a58 819b3eb3 [177459.383532] Call Trace: [177459.392878] IRQ [177459.392935] [8110ee7f] mod_timer_pending+0x3f/0xe0 [177459.411058] [810fb261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [177459.419876] [819b3eb3] __nf_ct_refresh_acct+0xa3/0xb0 [177459.428642] [819baafb] tcp_packet+0xb3b/0x1290 [177459.437285] [81a2535e] ? ip_output+0x5e/0xc0 [177459.445845] [810ca8ca] ? __local_bh_enable_ip+0x2a/0x90 [177459.454331] [819b35a9] ? __nf_conntrack_find_get+0x129/0x2a0 [177459.462642] [819b549c] nf_conntrack_in+0x29c/0x7c0 [177459.470711] [81a65e9c] ipv4_conntrack_local+0x4c/0x50 [177459.478753] [819ad67c] nf_iterate+0x4c/0x80 [177459.486726] [81102437] ? generic_handle_irq+0x27/0x40 [177459.494634] [819ad714] nf_hook_slow+0x64/0xc0 [177459.502486] [81a22d40] __ip_local_out_sk+0x90/0xa0 [177459.510248] [81a22c40] ? ip_forward_options+0x1a0/0x1a0 [177459.517782] [81a22d66] ip_local_out_sk+0x16/0x40 [177459.525044] [81a2343d] ip_queue_xmit+0x14d/0x350 [177459.532247] [81a3ae7e] tcp_transmit_skb+0x48e/0x960 [177459.539413] [81a3cddb] tcp_xmit_probe_skb+0xdb/0xf0 [177459.546389] [81a3dffb] tcp_write_wakeup+0x5b/0x150 [177459.553061] [81a3e51b] tcp_keepalive_timer+0x1fb/0x230 [177459.559761] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.566447] [8110f3c7] call_timer_fn.isra.27+0x17/0x80 [177459.573121] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.579778] [8110f55d] run_timer_softirq+0x12d/0x200 [177459.586448] [810ca6c3] __do_softirq+0x103/0x210 [177459.593138] [810ca9cb] irq_exit+0x4b/0xa0 [177459.599783] [814f05d4] xen_evtchn_do_upcall+0x34/0x50 [177459.606300] [81af93ae] xen_do_hypervisor_callback+0x1e/0x40 [177459.612583] EOI [177459.612637] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.625010] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.631157] [81008d60] ? xen_safe_halt+0x10/0x20 [177459.637158] [810188d3] ? default_idle+0x13/0x20 [177459.643072] [81018e1a] ? arch_cpu_idle+0xa/0x10 [177459.648809] [810f8e7e] ? default_idle_call+0x2e/0x50 [177459.654650] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [177459.660488] [81ae79f7] ? rest_init+0x77/0x80 [177459.666297] [82312f58] ? start_kernel+0x43b/0x448 [177459.672092] [823124ef] ? x86_64_start_reservations+0x2a/0x2c [177459.677800] [82316008] ? xen_start_kernel+0x550/0x55c
[Xen-devel] [xen-4.2-testing test] 60704: tolerable FAIL - PUSHED
flight 60704 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/60704/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-win7-amd64 17 guest-stop fail like 58892 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 58892 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 58892 test-amd64-i386-xl-win7-amd64 17 guest-stop fail like 58892 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a build-i386-rumpuserxen5 rumpuserxen-buildfail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass test-i386-i386-xl-qcow2 9 debian-di-installfail never pass test-amd64-i386-xl-qcow2 9 debian-di-installfail never pass test-amd64-amd64-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-qcow2 9 debian-di-installfail never pass test-i386-i386-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-i386-pvgrub 10 guest-start fail never pass test-amd64-amd64-amd64-pvgrub 10 guest-start fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qcow2 9 debian-di-installfail never pass test-i386-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-i386-i386-libvirt-raw 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-i386-i386-libvirt-vhd 11 migrate-support-checkfail 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-xend-qemut-winxpsp3 21 leak-check/checkfail never pass test-amd64-i386-xend-winxpsp3 21 leak-check/check fail never pass version targeted for testing: xen 32894093072c6ac5e680541669b0d1db263745fa baseline version: xen 38fcda225d6613ecc4bf44769806887252d7b2b1 Last test of basis58892 2015-06-25 05:21:03 Z 53 days Failing since 60150 2015-07-30 18:44:41 Z 17 days3 attempts Testing same since60675 2015-08-12 13:40:44 Z4 days2 attempts People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com David Scott dave.sc...@citrix.com Ian Campbell ian,campb...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jim Fehlig jfeh...@suse.com Kevin Wolf kw...@redhat.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Matthew Daley mat...@gmail.com Wei Liu wei.l...@citrix.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-qemuu-freebsd10-amd64
[Xen-devel] [libvirt bisection] complete build-i386-libvirt
branch xen-unstable xen branch xen-unstable job build-i386-libvirt test libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: libvirt git://libvirt.org/libvirt.git Bug introduced: 834c5720e4434f0bcc807bb1cf20855af63e24a3 Bug not present: b5d63e997bb4cbaa3c9d5e35e38998b0c1e78fd1 commit 834c5720e4434f0bcc807bb1cf20855af63e24a3 Author: Erik Skultety eskul...@redhat.com Date: Mon Jun 15 18:53:58 2015 +0200 tools: Introduce new client generic module vsh In order to share as much virsh' logic as possible with upcomming virt-admin client we need to split virsh logic into virsh specific and client generic features. Since majority of virsh methods should be generic enough to be used by other clients, it's much easier to rename virsh specific data to virshX than doing this vice versa. It moved generic virsh commands (including info and opts structures) to generic module vsh.c. Besides renaming methods and structures, this patch also involves introduction of a client specific control structure being referenced as private data in the original control structure, introduction of a new global vsh Initializer, which currently doesn't do much, but there is a potential for added functionality in the future. Lastly it introduced client hooks which are especially necessary during client connecting phase. For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-i386-libvirt.libvirt-build.html Revision IDs in each graph node refer, respectively, to the Trees above. Searching for failure / basis pass: 60708 fail [host=nocera1] / 60681 [host=nocera0] 60663 ok. Failure / basis pass flights: 60708 / 60663 (tree with no url: ovmf) (tree with no url: seabios) Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest 834c5720e4434f0bcc807bb1cf20855af63e24a3 f39477dba778e99392948dd3dd19ec0d46aee932 7f057440b31da38196e3398fd1b618fc36ad97d6 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 Basis pass 133c25c81c9ef79053d8d67a1e897846f9d7adb5 f39477dba778e99392948dd3dd19ec0d46aee932 7f057440b31da38196e3398fd1b618fc36ad97d6 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 Generating revisions with ./adhoc-revtuple-generator git://libvirt.org/libvirt.git#133c25c81c9ef79053d8d67a1e897846f9d7adb5-834c5720e4434f0bcc807bb1cf20855af63e24a3 git://git.sv.gnu.org/gnulib.git#f39477dba778e99392948dd3dd19ec0d46aee932-f39477dba778e99392948dd3dd19ec0d46aee932 git://xenbits.xen.org/staging/qemu-xen-unstable.git#7f057440b31da38196e3398fd1b618fc36ad97d6-7f057440b31da38196e3398fd1b618fc36ad97d6 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa-bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa git://xenbits.xen.org/xen.git#201eac83831d94ba2e9a63a7eed4c128633fafb1-201eac83831d94ba2e9a63a7eed4c128633fafb1 + exec + sh -xe + cd /home/osstest/repos/libvirt + git remote set-url origin git://cache:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /home/osstest/repos/libvirt + git remote set-url origin git://cache:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* Loaded 1001 nodes in revision graph Searching for test results: 60681 [host=nocera0] 60735 fail 834c5720e4434f0bcc807bb1cf20855af63e24a3 f39477dba778e99392948dd3dd19ec0d46aee932 7f057440b31da38196e3398fd1b618fc36ad97d6 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60663 pass 133c25c81c9ef79053d8d67a1e897846f9d7adb5 f39477dba778e99392948dd3dd19ec0d46aee932 7f057440b31da38196e3398fd1b618fc36ad97d6 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60708 fail 834c5720e4434f0bcc807bb1cf20855af63e24a3 f39477dba778e99392948dd3dd19ec0d46aee932 7f057440b31da38196e3398fd1b618fc36ad97d6 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60734 pass 133c25c81c9ef79053d8d67a1e897846f9d7adb5 f39477dba778e99392948dd3dd19ec0d46aee932 7f057440b31da38196e3398fd1b618fc36ad97d6 bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 201eac83831d94ba2e9a63a7eed4c128633fafb1 60736 pass 1b08cc170a84077afd4d15f4639a9a2cf398e9a2
[Xen-devel] [linux-linus test] 60709: regressions - FAIL
flight 60709 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/60709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-xsm 14 guest-saverestore fail REGR. vs. 59254 test-amd64-i386-xl 14 guest-saverestore fail REGR. vs. 59254 test-amd64-i386-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 59254 test-armhf-armhf-libvirt-raw 6 xen-bootfail baseline untested test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 59254 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 59254 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail never pass test-armhf-armhf-xl-qcow2 9 debian-di-installfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt 14 guest-saverestorefail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-raw 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt-vhd 9 debian-di-installfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-xl-raw 9 debian-di-installfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: linux45e38cff4fce8d6871b5fa5e734e4dc9814d6056 baseline version: linux45820c294fe1b1a9df495d57f40585ef2d069a39 Last test of basis59254 2015-07-09 04:20:48 Z 39 days Failing since 59348 2015-07-10 04:24:05 Z 38 days 28 attempts Testing same since60709 2015-08-15 09:56:21 Z2 days1 attempts 807 people touched revisions under test, not listing them all jobs:
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 2
On 2015/8/17 18:36, Roger Pau Monné wrote: El 11/08/15 a les 16.19, Ian Campbell ha escrit: On Fri, 2015-08-07 at 10:11 +0800, Shannon Zhao wrote: This document is going to explain the design details of Xen booting with ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are welcome. Some small subsets of this seem like they might overlap with what will be required for PVH on x86 (a new x86 guest mode not dissimilar to the sole ARM guest mode). If so then it would be preferable IMHO if PVH x86 could use the same interfaces. I've trimmed the quotes to just those bits and CCd some of the PVH people (Boris and Roger[0]) in case they have any thoughts. Actually, having done the trimming there is only one such bit: [...] 4. Map MMIO regions --- Register a bus_notifier for platform and amba bus in Linux. Add a new XENMAPSPACE XENMAPSPACE_dev_mmio. Within the register, check if the device is newly added, then call hypercall XENMEM_add_to_physmap to map the mmio regions. Ian. [0] Roger is away for a week or so, but I'm expect feedback to be of the we could use one extra field type rather than this needs to be done some totally different way for x86/PVH (in which case we wouldn't want to share the interface anyway I suppose) so need to block on awaiting that feedback. This looks right to me. AFAICT this new memory space (XENMAPSPACE_dev_mmio) will only be available to the hardware domain on x86. I expect that for DomUs the toolstack will already map the appropriate MMIO regions when creating the domain if there are pass-through devices assigned, not sure if that's also the plan on ARM. IMHO this document should also list the usage of the hypercall parameters: - space: XENMAPSPACE_dev_mmio. - idxs: native physical addresses. - gpfns: guest physical addresses where the mapping should appear. This is quite obvious but I think it's worth spelling it out. Will add. Thanks :) -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
Hi Julien,
On 2015/8/18 0:10, Julien Grall wrote:
Hi,
On 17/08/2015 06:01, Shannon Zhao wrote:
On 2015/8/14 23:17, Julien Grall wrote:
On 14/08/15 15:59, Shannon Zhao wrote:
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and size of uefi system table, address and size
of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
An example of the minimal DT:
/ {
#address-cells = 2;
#size-cells = 1;
chosen {
bootargs = kernel=Image console=hvc0
earlycon=pl011,0x1c09
root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force;
linux,initrd-start = 0x;
linux,initrd-end = 0x;
linux,uefi-system-table = 0x;
linux,uefi-mmap-start = 0x;
linux,uefi-mmap-size = 0x;
linux,uefi-mmap-desc-size = 0x;
linux,uefi-mmap-desc-ver = 0x;
};
};
For details loook at
https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt
I would have expect a summary on the discussion we had on the previous
thread [1].
Note that linux,initrd-* are well defined given that Xen, U-boot and
other bootloaders are using them. And IIRC, it's Linux specific.
Although, linux,uefi-* are not well defined (only used internally by
Linux betwen the EFI stub and the kernel) and we expect other OS to use
them in the future.
So I would prefer to the linux, dropped for them.
Yes, I think it's good to drop the linux, too. But if we drop the
linux, would it impact the linux kernel booting with UEFI? And why we
don't do it to Xen since Xen still uses linux,?
I don't understand your second question.
I mean that Xen is using the property linux,uefi* as well, and why we
don't drop that prefix for Xen?
For the first question, as we discussed in several mail, the property
linux,uefi-* are only used internally between the stub and Linux. The
sub is compiled in the kernel so there is no issue to change the property.
Since Linux defines the dt_params like below which is used to get EFI
info from DT, if we drop linux, in Xen, does it need to drop the
linux, in dt_params? If so, will this break the compatibility of
changed kernel with old UEFI? IIUC, there is not only Xen using these
properties, but also native host and QEMU guest.
static __initdata struct {
const char name[32];
const char propname[32];
int offset;
int size;
} dt_params[] = {
UEFI_PARAM(System Table, linux,uefi-system-table, system_table),
UEFI_PARAM(MemMap Address, linux,uefi-mmap-start, mmap),
UEFI_PARAM(MemMap Size, linux,uefi-mmap-size, mmap_size),
UEFI_PARAM(MemMap Desc. Size, linux,uefi-mmap-desc-size, desc_size),
UEFI_PARAM(MemMap Desc. Version, linux,uefi-mmap-desc-ver, desc_ver)
};
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 05/23] x86/boot/reloc: create generic alloc and copy functions
On Mon, Aug 17, 2015 at 09:51:58AM -0600, Jan Beulich wrote: On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote: Create generic alloc and copy functions. We need separate tools for memory allocation and copy to provide multiboot2 protocol support. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com --- v2 - suggestions/fixes: - generalize new functions names (suggested by Jan Beulich), - reduce number of casts (suggested by Jan Beulich). This contradicts retaining Andrew's R-b tag. Please remember to drop tags for everything you make non-trivial changes to. OK. @@ -55,50 +56,64 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes) sub %1,%0 \n and $~15,%0 \n mov %0,alloc-1b(%%edx) \n -mov %0,%%edi\n -rep movsb \n - : =r (new), +c (bytes), +S (old) - : : edx, edi, memory); -return new; + : =r (s) : r (bytes) : edx, memory); Can't bytes use a simple g constraint now? Works... Preferably (i.e. if correct) this changed ..., so, I will change that. Acked-by: Jan Beulich jbeul...@suse.com Thanks! Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
Hi Jan, On 2015/8/17 23:33, Jan Beulich wrote: On 14.08.15 at 16:59, shannon.z...@linaro.org wrote: 1. Copy and change some EFI and ACPI tables --- While some explanation on the reasons for this was given in the past discussion, I'm still missing a word on the why for each of these here. a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor, VendorGuid, VendorTable, ConfigurationTable. These changes are not very special and it just assign values to these members. I continue to question the need for fiddling with this table, not the least because I don't see how you intend to hand it to the Dom0 kernel: Are you expecting to call the kernel's ordinary EFI entry point, despite it not itself running on EFI firmware? Dom0 gets UEFI info from the minimal DT when booting with UEFI. And the main purpose to create a EFI_SYSTEM_TABLE is to provide the ACPI table root (RSDP) address to Dom0, so it could find the ACPI table. Here since we don't support RUNTIME service fro Dom0 currently, we could set the Attribute of EFI_SYSTEM_TABLE memory region to not be EFI_MEMORY_RUNTIME or pass kernel command parameter efi=noruntime to disable RUNTIME service. b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and size information of Dom0. And Dom0 will get the memory information through this EFI table. To some degree the same applies here: While I see that you have no legacy vehicle like x86's E820, I also don't see how Dom0 - not being able to make EFI boot or runtime services calls - would get hold of this table. And if a non-EFI mechanism is to be used here, using the EFI data structure would turn out to be just an arbitrary (or convenience) decision, not something inherently required. Which I think should be said explicitly if so, rather than leaving the reader guess. c) Copy FADT table. Change the value of arm_boot_flags to enable PSCI and HVC. Let the hypervisor_id be XenVMM in order to tell Dom0 that it runs on Xen hypervisor, then Dom0 could through HVM_PARAM to get some informations for booting necessity, such as event-channel interrupt. Change header revison, length and checksum as well. d) Copy MADT table. According to the value of dom0_max_vcpus to change the number GICC entries. e) Create STAO table. This table is a new added one that's used to define a list of ACPI namespace names that are to be ignored by the OSPM in Dom0. Currently we use it to tell OSPM should ignore UART defined in SPCR table. f) Copy XSDT table. Add a new table entry for STAO and change other table's entries. g) Change the value of xsdt_physical_address in RSDP table. Which RSDP? Under EFI the table root is to be found from the EFI Configuration Table. Yes, the RSDP address is stored in EFI Configure Table. And RSDP table has a field xsdt_physical_address that points to the XSDT table. As we create a new XSDT and the address of XSDT is changed, so it needs to update the value of xsdt_physical_address in RSDP. So Dom0 could get the right XSDT table rather than the old one. Thanks, -- Shannon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API
On 8/13/2015 at 05:09 PM, in message
20150813090938.gi7...@zion.uk.xensource.com, Wei Liu wei.l...@citrix.com
wrote:
On Tue, Aug 11, 2015 at 08:24:01PM -0600, Chun Yan Liu wrote:
On 8/11/2015 at 07:27 PM, in message
2015082702.gf7...@zion.uk.xensource.com, Wei Liu
wei.l...@citrix.com
wrote:
On Mon, Aug 10, 2015 at 06:35:24PM +0800, Chunyan Liu wrote:
Add pvusb APIs, including:
- attach/detach (create/destroy) virtual usb controller.
- attach/detach usb device
- list usb controller and usb devices
- some other helper functions
Signed-off-by: Chunyan Liu cy...@suse.com
Signed-off-by: Simon Cao caobosi...@gmail.com
---
changes:
- Address George's comments:
* Update libxl_device_usb_getinfo to read ctrl/port only and
get other information.
* Update backend path according to xenstore frontend 'xxx/backend'
entry instead of using TOOLSTACK_DOMID.
* Use 'type' to indicate qemu/pv instead of previous naming
'protocol'.
* Add USB 'devtype' union, currently only includes hostdev
I will leave this to Ian and George since they had strong opinions on
this.
I only skimmed this patch. Some comments below.
[...]
+
+int libxl_device_usb_getinfo(libxl_ctx *ctx, uint32_t domid,
+ libxl_device_usb *usb,
+ libxl_usbinfo *usbinfo);
+
/* Network Interfaces */
int libxl_device_nic_add(libxl_ctx *ctx, uint32_t domid,
libxl_device_nic
*nic,
const libxl_asyncop_how *ao_how)
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index bee5ed5..935f25b 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -676,6 +676,10 @@ void libxl__devices_destroy(libxl__egc *egc,
libxl__devices_remove_state *drs)
aodev-action = LIBXL__DEVICE_ACTION_REMOVE;
aodev-dev = dev;
aodev-force = drs-force;
+if (dev-backend_kind == LIBXL__DEVICE_KIND_VUSB) {
+libxl__initiate_device_usbctrl_remove(egc, aodev);
+continue;
+}
Is there a risk that this races with individual device removal? I think
you get away with it because removal of individual device is idempotent?
You mean races with other device removal (like 'vbd') ? Yes, it is
idempotent.
Only for 'vusb' (corresponding to USB controller), before removing USB
controller
it will first removing all USB devices under it.
No. What I mean is, the removal of usbctrl triggers removal of all
assigned usb devices. And then this function initiates removal of
assigned usb devices again. Is this a possible scenario?
libxl__initiate_device_remove(egc, aodev);
}
}
diff --git a/tools/libxl/libxl_internal.h
b/tools/libxl/libxl_internal.h
index f98f089..5be3b3a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2553,6 +2553,14 @@ _hidden void libxl__device_vtpm_add(libxl__egc
*egc,
uint32_t domid,
libxl_device_vtpm *vtpm,
libxl__ao_device *aodev);
+_hidden void libxl__device_usbctrl_add(libxl__egc *egc, uint32_t
domid,
+ libxl_device_usbctrl *usbctrl,
+ libxl__ao_device *aodev);
+
+_hidden void libxl__device_usb_add(libxl__egc *egc, uint32_t domid,
+ libxl_device_usb *usb,
+ libxl__ao_device *aodev);
+
/* Internal function to connect a vkb device */
_hidden int libxl__device_vkb_add(libxl__gc *gc, uint32_t domid,
libxl_device_vkb *vkb);
@@ -2585,6 +2593,13 @@ _hidden void
libxl__wait_device_connection(libxl__egc*,
_hidden void libxl__initiate_device_remove(libxl__egc *egc,
libxl__ao_device *aodev);
+_hidden int libxl__device_from_usbctrl(libxl__gc *gc, uint32_t domid,
[...]
+void libxl__device_usb_add(libxl__egc *egc, uint32_t domid,
+ libxl_device_usb *usb,
+ libxl__ao_device *aodev)
+{
+STATE_AO_GC(aodev-ao);
+int rc = -1;
+char *busid = NULL;
+
+assert(usb-u.hostdev.hostbus 0 usb-u.hostdev.hostaddr 0);
+
+busid = usb_busaddr_to_busid(gc, usb-u.hostdev.hostbus,
+
Re: [Xen-devel] Could Xen hyperviosr be able to invoke Linux systemcalls?
On Tue, Aug 18, 2015 at 3:25 AM Dario Faggioli dario.faggi...@citrix.com wrote: On Mon, 2015-08-17 at 00:55 +, Kun Cheng wrote: On Mon, Aug 17, 2015 at 12:16 AM Frediano Ziglio fredd...@gmail.com What I'm planing is adding page migration support for NUMA aware scheduling. In such a case the most time I'll be dealing with Xen's memory management scheduling part to make relevant pages migrate to another node with their VCPU. However, Linux kernel has already implemented some basic mechanisms so the whole work would be better by leveraging the kernel's existing code or functions. No, not at all. As you figured (or at least had intuition about) yourself, Xen does run below Linux. Actually, it runs below any guest, including Dom0, which is a special guest but still a guest, and can even not be a Linux guest. So there's no code sharing, or no mechanism to invoke Linux code and have it affect Xen's scheduling or memory management (and never will be :-P). Thank you Dario and Frediano. Not being able to share the existing kernel mechanism is some kind of frustrating..But just as you said it's the point of virtualization. And now I gain a better understanding why you said it would be tough ;) (I start to envy KVM guys, LOL) More specifically, I want to confirm that could we use the code or functions in linux kernel to assist the hypervisor? No, it's the other way around. My guess is not because in my understanding xen hypervisor lies under the linux kernel, i.e. dom0's kernel. Exactly. Given that Dom0 is a special domain, if I want to manage move all the machine memory pages, can the kernel be helpful? The Dom0 kernel doesn't know anything about the memory of other guest. It basically doesn't even know that they exist... That's the point of virtualization, isn't it? Also Linux's and Xen's scheduling and memory management are so different (and that's by design) that, even for similar (or the same) feature, the implementation will be different anyway, so sharing the code won't help at all. Hmm, change the memory from dom0 means we can control the VM's memory by using a config file or xl command right? changing the memory from dom0 means something like the dom0 can ask Xen, via toolstack, to do something to the memory of other guests, i.e., it has enough privileges to do that, but that's it. What if we goes to the code level? I'm really confused now. Is Xen's memory management complemented all by itsself or does it also receive help from the kernel? As said, Xen doesn't even know what kernel is actually running in the various guest, including dom0, and things should remains that way, especially for core things like scheduling and memory management. So, in summary, what you're after should be achieved entirely inside Xen. It is possible than, in the PV guest case, you'd need some help from the guest. However, that would be in the form of Xen asking/forcing the guest to do something on the *guest* *itself*, not in the form of Xen asking dom0 to do something on Xen's own memory/scheduling or (directly) on other guests' memory. Hope this helps clearing things out for you. :-) At this point I still have other plans. But 'asking the guest to do something on the guest itself' sounds like exposing the virtual NUMA topology to the guest (vNUMA). I wrote this email because hypervisor is responsible to allocate machine memory for each guest. Then, in a PV case there are P2M and M2P to help address translation (and shadow page tables in HVMs). So what first came to my mind was hypervisor should move the pages for guests and then P2M things should better be renewed somehow. However inside a guest domain, its OS can only manage the guest physical memory, which I don't think is able to be moved to another node by itself. Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) Maybe I misunderstood you words... 'asking the guest to do something on the guest itself' confuses me a bit, could you explain more details of your thought if it's convenient for you? Thank you, Kenneth ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
This is very similar to the behavior I am seeing in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=102911 -Jon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-4.4-testing test] 60673: regressions - FAIL
On 16.08.15 at 11:14, ian.campb...@citrix.com wrote: On Fri, 2015-08-14 at 04:07 -0600, Jan Beulich wrote: If so, I'd be inclined to suggest a force push based on this flight. Overall I think I'm inclined to agree, I suppose your motive is that you want to get 4.4.x+1 out the door and I don't think we should block that over this issue. Right. Flight 60696 shows exactly the same single failure. Could one of you two force-push then please? Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode
On 12/08/15 14:33, Andrew Cooper wrote: On 12/08/15 14:29, Andrew Cooper wrote: On 11/08/15 19:29, Boris Ostrovsky wrote: On 08/11/2015 01:19 PM, Andrew Cooper wrote: On 11/08/15 18:05, Tim Deegan wrote: * Under this model, PV exception handlers should copy themselves onto the privileged execution stack. * Currently, the IST handlers copy themselves onto the primary stack if they interrupt guest context. * AMD Task Register on vmexit. (this old gem) Gah, this thing. : Curious (and I can't seem find this in the manuals): What is this thing? IIRC: AMD processors don't context switch TR on vmexit, Correct which makes using IST handlers tricky there. (That is one way of putting it) IST handlers cannot be used by Xen if Xen does not switch the task register before stgi, or IST exceptions (NMI, MCE and double fault) will be taken with guest-supplied stack pointers. We'd have to do the TR context switch ourselves, and that would be expensive. It is suspected to be expensive, but I have never actually seen any numbers one way or another. Andrew, am I remembering that right? Looks about right. I have been meaning to investigate this for a while, but never had the time. Xen opts for disabling interrupt stack tables in the context of AMD HVM vcpus, which interacts catastrophically with debug builds using MEMORY_GUARD. MEMORY_GUARD shoots a page out of the primary stack to detect stack overflows, but without an IST double fault hander, ends in a triple fault rather than a host crash detailing the stack overflow. KVM unilaterally reloads the host task register on vmexit, and I suspect this is probably the way to go, but have not had time to investigate whether there is any performance impact from doing so. Given how little of a TSS is actually used in long mode, I wouldn't expect an `ltr` to be as expensive as it might have been in legacy modes. (CC'ing the AMD SVM maintainers to see if they have any information on this subject) I actually didn't even realize that TR is not saved on vmexit ;-/. Would switching TR only when we know that we need to enter this deprivileged mode help? This is an absolute must. It is not safe to use syscall/sysexit without IST in place for NMIs and MCEs. Assuming that it is less expensive than copying the stack. I was referring to the stack overflow issue, and whether it might be sensible to pro-actively which TR. Ahem! s/which/switch/ ~Andrew So, have we arrived at a decision for this? Thanks! Ben ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
Monday, August 17, 2015, 3:37:13 PM, you wrote: On Mon, 2015-08-17 at 11:09 +0200, Sander Eikelenboom wrote: Saturday, August 15, 2015, 12:39:25 AM, you wrote: On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote: On 2015-08-13 00:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is breaking things (have to test if a revert helps) i get this in some guests: Yes, this was fixed by : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af Hi Eric, With that patch i had a crash again this night, see below. -- Sander [177459.188808] general protection fault: [#1] SMP [177459.199746] Modules linked in: [177459.210540] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150815-linus-doflr-net+ #1 [177459.221441] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [177459.232247] task: 8221a580 ti: 8220 task.ti: 8220 [177459.242931] RIP: e030:[8110eb58] [8110eb58] detach_if_pending+0x18/0x80 [177459.253503] RSP: e02b:88005f6039d8 EFLAGS: 00010086 [177459.264051] RAX: 8800584d6580 RBX: 880004901420 RCX: dead00200200 [177459.274599] RDX: RSI: 88005f60e5c0 RDI: 880004901420 [177459.285122] RBP: 88005f6039d8 R08: 0001 R09: [177459.295286] R10: 0003 R11: 880004901394 R12: 0003 [177459.305388] R13: 00010ae47040 R14: 07b98a00 R15: 88005f60e5c0 [177459.315345] FS: 7f51317ec700() GS:88005f60() knlGS: [177459.325340] CS: e033 DS: ES: CR0: 8005003b [177459.335217] CR2: 010f8000 CR3: 2a154000 CR4: 0660 [177459.345129] Stack: [177459.354783] 88005f603a28 8110ee7f 810fb261 0200 [177459.364505] 0003 880004901380 0003 8800567d0d00 [177459.374064] 07b98a00 88005f603a58 819b3eb3 [177459.383532] Call Trace: [177459.392878] IRQ [177459.392935] [8110ee7f] mod_timer_pending+0x3f/0xe0 [177459.411058] [810fb261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [177459.419876] [819b3eb3] __nf_ct_refresh_acct+0xa3/0xb0 [177459.428642] [819baafb] tcp_packet+0xb3b/0x1290 [177459.437285] [81a2535e] ? ip_output+0x5e/0xc0 [177459.445845] [810ca8ca] ? __local_bh_enable_ip+0x2a/0x90 [177459.454331] [819b35a9] ? __nf_conntrack_find_get+0x129/0x2a0 [177459.462642] [819b549c] nf_conntrack_in+0x29c/0x7c0 [177459.470711] [81a65e9c] ipv4_conntrack_local+0x4c/0x50 [177459.478753] [819ad67c] nf_iterate+0x4c/0x80 [177459.486726] [81102437] ? generic_handle_irq+0x27/0x40 [177459.494634] [819ad714] nf_hook_slow+0x64/0xc0 [177459.502486] [81a22d40] __ip_local_out_sk+0x90/0xa0 [177459.510248] [81a22c40] ? ip_forward_options+0x1a0/0x1a0 [177459.517782] [81a22d66] ip_local_out_sk+0x16/0x40 [177459.525044] [81a2343d] ip_queue_xmit+0x14d/0x350 [177459.532247] [81a3ae7e] tcp_transmit_skb+0x48e/0x960 [177459.539413] [81a3cddb] tcp_xmit_probe_skb+0xdb/0xf0 [177459.546389] [81a3dffb] tcp_write_wakeup+0x5b/0x150 [177459.553061] [81a3e51b] tcp_keepalive_timer+0x1fb/0x230 [177459.559761] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.566447] [8110f3c7] call_timer_fn.isra.27+0x17/0x80 [177459.573121] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.579778] [8110f55d] run_timer_softirq+0x12d/0x200 [177459.586448] [810ca6c3] __do_softirq+0x103/0x210 [177459.593138] [810ca9cb] irq_exit+0x4b/0xa0 [177459.599783] [814f05d4] xen_evtchn_do_upcall+0x34/0x50 [177459.606300] [81af93ae] xen_do_hypervisor_callback+0x1e/0x40 [177459.612583] EOI [177459.612637] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.625010] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.631157] [81008d60] ? xen_safe_halt+0x10/0x20 [177459.637158] [810188d3] ? default_idle+0x13/0x20 [177459.643072] [81018e1a] ? arch_cpu_idle+0xa/0x10 [177459.648809] [810f8e7e] ? default_idle_call+0x2e/0x50 [177459.654650] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [177459.660488] [81ae79f7] ? rest_init+0x77/0x80
Re: [Xen-devel] [PATCH] libxenstore: Use poll() with a non-blocking read()
On 08/16/2015 08:46 PM, Jonathan Creekmore wrote:
On Aug 16, 2015, at 1:59 AM, Ian Campbell ian.campb...@citrix.com wrote:
On Thu, 2015-08-13 at 16:44 -0500, Jonathan Creekmore wrote:
With the addition of FMODE_ATOMIC_POS in the Linux 3.14 kernel,
concurrent blocking file accesses to a single open file descriptor can
cause a deadlock trying to grab the file position lock. If a watch has
been set up, causing a read_thread to blocking read on the file
descriptor, then future writes that would cause the background read to
complete will block waiting on the file position lock before they can
execute.
This sounds like you are describing a kernel bug. Shouldn't this be
fixed in the kernel?
It is a bug in the sense that addition of FMODE_ATOMIC_POS changed
user-visible behavior. And a fix was suggested in
http://permalink.gmane.org/gmane.linux.file-systems/93969 .
Copying Vitalii who sent an early version of that patch.
-boris
In fact it even sounds a bit familiar, I wonder if it is fixed in some
version of Linux 3.14? (CCing a few relevant maintainers)
So, the latest I saw on the LKML, the problem still existed as of 3.17 and,
looking forward through 4.2, the problem still exists there as well. I saw a
few posts back in March 2015 talking about the deadlock, but it appeared to
have gotten no traction. It isn’t a deadlock in the kernel, but rather a
deadlock between the two blocking reads or a blocking read or write. The slight
rewrite I applied in my patch effectively works around the problem and prevents
the library from flip-flopping the nonblocking flag on the file descriptor
between two threads.
This race condition only occurs when libxenstore is accessing
the xenstore daemon through the /proc/xen/xenbus file and not through
the unix domain socket, which is the case when the xenstore daemon is
running as a stub domain or when oxenstored is passed --disable-socket.
Arguably, since the /proc/xen/xenbus file is declared nonseekable, then
the file position lock need not be grabbed, since the file cannot be
seeked. However, that is not how the kernel API works. On the other
hand, using the poll() API to implement the blocking for the read_all()
function prevents the file descriptor from being switched back and forth
between blocking and non-blocking modes between two threads.
Signed-off-by: Jonathan Creekmore jonathan.creekm...@gmail.com
---
tools/xenstore/xs.c | 52 ---
-
1 file changed, 16 insertions(+), 36 deletions(-)
diff --git a/tools/xenstore/xs.c b/tools/xenstore/xs.c
index d1e01ba..9b75493 100644
--- a/tools/xenstore/xs.c
+++ b/tools/xenstore/xs.c
@@ -31,6 +31,7 @@
#include signal.h
#include stdint.h
#include errno.h
+#include poll.h
#include xenstore.h
#include list.h
#include utils.h
@@ -145,22 +146,6 @@ struct xs_handle {
static int read_message(struct xs_handle *h, int nonblocking);
-static bool setnonblock(int fd, int nonblock) {
- int flags = fcntl(fd, F_GETFL);
- if (flags == -1)
- return false;
-
- if (nonblock)
- flags |= O_NONBLOCK;
- else
- flags = ~O_NONBLOCK;
-
- if (fcntl(fd, F_SETFL, flags) == -1)
- return false;
-
- return true;
-}
-
int xs_fileno(struct xs_handle *h)
{
char c = 0;
@@ -216,7 +201,7 @@ error:
static int get_dev(const char *connect_to)
{
/* We cannot open read-only because requests are writes */
- return open(connect_to, O_RDWR);
+ return open(connect_to, O_RDWR | O_NONBLOCK);
}
static struct xs_handle *get_handle(const char *connect_to)
@@ -365,42 +350,37 @@ static bool read_all(int fd, void *data,
unsigned int len, int nonblocking)
/* With nonblocking, either reads either everything
requested,
* or nothing. */
{
- if (!len)
- return true;
-
- if (nonblocking !setnonblock(fd, 1))
- return false;
+ int done;
+ struct pollfd fds[] = {
+ {
+ .fd = fd,
+ .events = POLLIN
+ }
+ };
while (len) {
- int done;
+ if (!nonblocking) {
+ if (poll(fds, 1, -1) 1) {
+ return false;
+ }
+ }
done = read(fd, data, len);
if (done 0) {
if (errno == EINTR)
continue;
- goto out_false;
+ return false;
}
if (done == 0) {
/* It closed fd on us? EBADF is
appropriate. */
errno = EBADF;
- goto out_false;
+ return false;
}
data += done;
len -= done;
-
- if (nonblocking) {
- nonblocking = 0;
-
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On Mon, 2015-08-17 at 11:09 +0200, Sander Eikelenboom wrote: Saturday, August 15, 2015, 12:39:25 AM, you wrote: On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote: On 2015-08-13 00:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is breaking things (have to test if a revert helps) i get this in some guests: Yes, this was fixed by : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af Hi Eric, With that patch i had a crash again this night, see below. -- Sander [177459.188808] general protection fault: [#1] SMP [177459.199746] Modules linked in: [177459.210540] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150815-linus-doflr-net+ #1 [177459.221441] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [177459.232247] task: 8221a580 ti: 8220 task.ti: 8220 [177459.242931] RIP: e030:[8110eb58] [8110eb58] detach_if_pending+0x18/0x80 [177459.253503] RSP: e02b:88005f6039d8 EFLAGS: 00010086 [177459.264051] RAX: 8800584d6580 RBX: 880004901420 RCX: dead00200200 [177459.274599] RDX: RSI: 88005f60e5c0 RDI: 880004901420 [177459.285122] RBP: 88005f6039d8 R08: 0001 R09: [177459.295286] R10: 0003 R11: 880004901394 R12: 0003 [177459.305388] R13: 00010ae47040 R14: 07b98a00 R15: 88005f60e5c0 [177459.315345] FS: 7f51317ec700() GS:88005f60() knlGS: [177459.325340] CS: e033 DS: ES: CR0: 8005003b [177459.335217] CR2: 010f8000 CR3: 2a154000 CR4: 0660 [177459.345129] Stack: [177459.354783] 88005f603a28 8110ee7f 810fb261 0200 [177459.364505] 0003 880004901380 0003 8800567d0d00 [177459.374064] 07b98a00 88005f603a58 819b3eb3 [177459.383532] Call Trace: [177459.392878] IRQ [177459.392935] [8110ee7f] mod_timer_pending+0x3f/0xe0 [177459.411058] [810fb261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [177459.419876] [819b3eb3] __nf_ct_refresh_acct+0xa3/0xb0 [177459.428642] [819baafb] tcp_packet+0xb3b/0x1290 [177459.437285] [81a2535e] ? ip_output+0x5e/0xc0 [177459.445845] [810ca8ca] ? __local_bh_enable_ip+0x2a/0x90 [177459.454331] [819b35a9] ? __nf_conntrack_find_get+0x129/0x2a0 [177459.462642] [819b549c] nf_conntrack_in+0x29c/0x7c0 [177459.470711] [81a65e9c] ipv4_conntrack_local+0x4c/0x50 [177459.478753] [819ad67c] nf_iterate+0x4c/0x80 [177459.486726] [81102437] ? generic_handle_irq+0x27/0x40 [177459.494634] [819ad714] nf_hook_slow+0x64/0xc0 [177459.502486] [81a22d40] __ip_local_out_sk+0x90/0xa0 [177459.510248] [81a22c40] ? ip_forward_options+0x1a0/0x1a0 [177459.517782] [81a22d66] ip_local_out_sk+0x16/0x40 [177459.525044] [81a2343d] ip_queue_xmit+0x14d/0x350 [177459.532247] [81a3ae7e] tcp_transmit_skb+0x48e/0x960 [177459.539413] [81a3cddb] tcp_xmit_probe_skb+0xdb/0xf0 [177459.546389] [81a3dffb] tcp_write_wakeup+0x5b/0x150 [177459.553061] [81a3e51b] tcp_keepalive_timer+0x1fb/0x230 [177459.559761] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.566447] [8110f3c7] call_timer_fn.isra.27+0x17/0x80 [177459.573121] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.579778] [8110f55d] run_timer_softirq+0x12d/0x200 [177459.586448] [810ca6c3] __do_softirq+0x103/0x210 [177459.593138] [810ca9cb] irq_exit+0x4b/0xa0 [177459.599783] [814f05d4] xen_evtchn_do_upcall+0x34/0x50 [177459.606300] [81af93ae] xen_do_hypervisor_callback+0x1e/0x40 [177459.612583] EOI [177459.612637] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.625010] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.631157] [81008d60] ? xen_safe_halt+0x10/0x20 [177459.637158] [810188d3] ? default_idle+0x13/0x20 [177459.643072] [81018e1a] ? arch_cpu_idle+0xa/0x10 [177459.648809] [810f8e7e] ? default_idle_call+0x2e/0x50 [177459.654650] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [177459.660488] [81ae79f7] ? rest_init+0x77/0x80 [177459.666297] [82312f58] ?
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
Monday, August 17, 2015, 4:21:47 PM, you wrote: On Mon, 2015-08-17 at 09:02 -0500, Jon Christopherson wrote: This is very similar to the behavior I am seeing in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=102911 OK, but have you applied the fix ? http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af It will be part of net iteration from David Miller to Linus Torvald. I did have that patch in for my last report. But i don't think he had (looking at the second part of his oops). -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On Mon, 2015-08-17 at 09:02 -0500, Jon Christopherson wrote: This is very similar to the behavior I am seeing in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=102911 OK, but have you applied the fix ? http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af It will be part of net iteration from David Miller to Linus Torvald. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
On 2015/8/14 23:17, Julien Grall wrote:
On 14/08/15 15:59, Shannon Zhao wrote:
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and size of uefi system table, address and size
of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
An example of the minimal DT:
/ {
#address-cells = 2;
#size-cells = 1;
chosen {
bootargs = kernel=Image console=hvc0 earlycon=pl011,0x1c09
root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force;
linux,initrd-start = 0x;
linux,initrd-end = 0x;
linux,uefi-system-table = 0x;
linux,uefi-mmap-start = 0x;
linux,uefi-mmap-size = 0x;
linux,uefi-mmap-desc-size = 0x;
linux,uefi-mmap-desc-ver = 0x;
};
};
For details loook at
https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt
I would have expect a summary on the discussion we had on the previous
thread [1].
Note that linux,initrd-* are well defined given that Xen, U-boot and
other bootloaders are using them. And IIRC, it's Linux specific.
Although, linux,uefi-* are not well defined (only used internally by
Linux betwen the EFI stub and the kernel) and we expect other OS to use
them in the future.
So I would prefer to the linux, dropped for them.
Yes, I think it's good to drop the linux, too. But if we drop the
linux, would it impact the linux kernel booting with UEFI? And why we
don't do it to Xen since Xen still uses linux,?
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode
On 11/08/15 11:33, Ben Catterall wrote:
On 10/08/15 11:07, Tim Deegan wrote:
Hi,
@@ -685,8 +685,17 @@ static int hap_page_fault(struct vcpu *v,
unsigned long va,
{
struct domain *d = v-domain;
+/* If we get a page fault whilst in HVM security user mode */
+if( v-user_mode == 1 )
+{
+printk(HVM: #PF (%u:%u) whilst in user mode\n,
+ d-domain_id, v-vcpu_id);
+domain_crash_synchronous();
+}
+
This should happen in paging_fault() so it can guard the
shadow-pagetable paths too. Once it's there, it'll need a check for
is_hvm_vcpu() as well as for user_mode. Maybe have a helper function
'is_hvm_deprivileged_vcpu()' to do both checks, also used in
hvm_deprivileged_check_trap() c.
I've moved this and now need to add shadow page table support as this
currently only supports HAP.
Ok, I'll make this change.
HAP_ERROR(Intercepted a guest #PF (%u:%u) with HAP enabled.\n,
d-domain_id, v-vcpu_id);
+
domain_crash(d);
return 0;
}
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 9f5a6c6..19d465f 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -74,6 +74,7 @@
#include asm/vpmu.h
#include public/arch-x86/cpuid.h
#include xsm/xsm.h
+#include xen/hvm/deprivileged.h
/*
* opt_nmi: one of 'ignore', 'dom0', or 'fatal'.
@@ -500,6 +501,11 @@ static void do_guest_trap(
struct trap_bounce *tb;
const struct trap_info *ti;
+/* If we take the trap whilst in HVM deprivileged mode
+ * then we should crash the domain.
+ */
+hvm_deprivileged_check_trap(__FUNCTION__);
I wonder whether it would be better to switch to an IDT with all
unacceptable traps stubbed out, rather than have to blacklist them all
separately. Probably not - this check is cheap, and maintaining the
parallel tables would be a pain.
Or maybe there's some single point upstream of here, in the asm
handlers, that would catch all the cases where this check is needed?
Yep, I think this can be done.
Had a deeper look at this. There is a point where all exceptions come in
in the asm (handle_exception in entry.S) and we could branch out at this
point. It does mean that we'd treat _all_ exceptions that occur in this
mode the same way whereas the current way means that we can treat them
differently (e.g. get __func__). So, should I make all exceptions go to
the same point or keep as is?
Thanks!
In any case, the check needs to return an error code so the caller
knows to return without running the rest of the handler (and likewise
elsewhere).
understood.
Cheers,
Tim.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On 08/17/2015 12:18 PM, Eric Dumazet wrote: From: Eric Dumazet eduma...@google.com snip Then can you try following fix as well ? Thanks ! [PATCH] timer: fix a race in __mod_timer() snip I have been running the latest code from git with the 2 patches in this thread applied. No issues so far. -Jon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On 08/17/2015 09:25 AM, Sander Eikelenboom wrote: OK, but have you applied the fix ? http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af It will be part of net iteration from David Miller to Linus Torvald. I did not have that fix applied, but will apply and test. Thanks, Jon ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 1/2] Differentiate IO/mem resources tracked by ioreq server
On 8/14/2015 9:51 PM, Paul Durrant wrote:
-Original Message-
From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
Sent: 14 August 2015 13:03
To: xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; Stefano Stabellini; Ian
Campbell; Wei Liu; Keir (Xen.org); jbeul...@suse.com; Andrew Cooper
Cc: Kevin Tian; zhiyuan...@intel.com
Subject: [PATCH v5 1/2] Differentiate IO/mem resources tracked by ioreq
server
Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each.
This patch uses a seperate rangeset for the guest ram pages.
And a new ioreq type, IOREQ_TYPE_WP_MEM, is defined.
Note: Previously, a new hypercall or subop was suggested to map
write-protected pages into ioreq server. However, it turned out
handler of this new hypercall would be almost the same with the
existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.
Signed-off-by: Yu Zhang yu.c.zh...@linux.intel.com
---
tools/libxc/include/xenctrl.h| 31 ++
tools/libxc/xc_domain.c | 55
xen/arch/x86/hvm/hvm.c | 25 +-
xen/include/asm-x86/hvm/domain.h | 4 +--
xen/include/public/hvm/hvm_op.h | 1 +
xen/include/public/hvm/ioreq.h | 1 +
6 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index de3c0ad..3c276b7 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2010,6 +2010,37 @@ int
xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch,
int is_mmio,
uint64_t start,
uint64_t end);
+/**
+ * This function registers a range of write-protected memory for emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
+
+/**
+ * This function deregisters a range of write-protected memory for
emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_unmap_mem_range_from_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
/**
* This function registers a PCI device for config space emulation.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 2ee26fb..9db05b3 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1552,6 +1552,61 @@ int
xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch, domid_t
domid,
return rc;
}
+int xc_hvm_map_mem_range_to_ioreq_server(xc_interface *xch,
domid_t domid,
+ioservid_t id, xen_pfn_t start,
xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_map_io_range_to_ioreq_server;
+hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+arg-domid = domid;
+arg-id = id;
+arg-type = HVMOP_IO_RANGE_WP_MEM;
+arg-start = start;
+arg-end = end;
+
+rc = do_xen_hypercall(xch, hypercall);
+
+xc_hypercall_buffer_free(xch, arg);
+return rc;
+}
+
+int xc_hvm_unmap_mem_range_from_ioreq_server(xc_interface *xch,
domid_t domid,
+ioservid_t id, xen_pfn_t start,
xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_unmap_io_range_from_ioreq_server;
+hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+arg-domid = domid;
+
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
Shannon Zhao zhaoshengl...@huawei.com 08/18/15 5:46 AM On 2015/8/17 23:33, Jan Beulich wrote: On 14.08.15 at 16:59, shannon.z...@linaro.org wrote: 1. Copy and change some EFI and ACPI tables --- While some explanation on the reasons for this was given in the past discussion, I'm still missing a word on the why for each of these here. a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor, VendorGuid, VendorTable, ConfigurationTable. These changes are not very special and it just assign values to these members. I continue to question the need for fiddling with this table, not the least because I don't see how you intend to hand it to the Dom0 kernel: Are you expecting to call the kernel's ordinary EFI entry point, despite it not itself running on EFI firmware? Dom0 gets UEFI info from the minimal DT when booting with UEFI. And the main purpose to create a EFI_SYSTEM_TABLE is to provide the ACPI table root (RSDP) address to Dom0, so it could find the ACPI table. For that passing the configuration table would suffice. The more that Julien in his reply said you're not even intending to use the kernel's EFI stub. I.e. the question remains: How would you expect to hand the System Table pointer to Dom0? Here since we don't support RUNTIME service fro Dom0 currently, we could set the Attribute of EFI_SYSTEM_TABLE memory region to not be EFI_MEMORY_RUNTIME or pass kernel command parameter efi=noruntime to disable RUNTIME service. I don't see how this part of your reply is related. g) Change the value of xsdt_physical_address in RSDP table. Which RSDP? Under EFI the table root is to be found from the EFI Configuration Table. Yes, the RSDP address is stored in EFI Configure Table. And RSDP table has a field xsdt_physical_address that points to the XSDT table. As we create a new XSDT and the address of XSDT is changed, so it needs to update the value of xsdt_physical_address in RSDP. So Dom0 could get the right XSDT table rather than the old one. Oh, sorry, I mixed things up. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
Julien Grall julien.gr...@citrix.com 08/17/15 6:27 PM On 17/08/2015 08:33, Jan Beulich wrote: On 14.08.15 at 16:59, shannon.z...@linaro.org wrote: b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and size information of Dom0. And Dom0 will get the memory information through this EFI table. To some degree the same applies here: While I see that you have no legacy vehicle like x86's E820, I also don't see how Dom0 - not being able to make EFI boot or runtime services calls - would get hold of this table. And if a non-EFI mechanism is to be used here, using the EFI data structure would turn out to be just an arbitrary (or convenience) decision, not something inherently required. Which I think should be said explicitly if so, rather than leaving the reader guess. It's not an arbitrary decision, when UEFI stub in Linux is using device tree properties to pass the UEFI table to the kernel ([1]). When booting on Xen with ACPI, dom0 will use the non-EFI entry point. The easiest way to pass the memory information to Linux is using the UEFI DT properties. In which case it is even more arbitrary to use the EFI data structure to convey memory information (instead of expressing it in plain DT, which is how I blindly assume non-EFI does it). Of course there's the small chance that UEFI DT properties implies a certain binary format, but it's still odd for a non-EFI entry point to assume EFI properties to be there... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode
At 14:59 +0100 on 17 Aug (1439823550), Ben Catterall wrote: On 11/08/15 11:33, Ben Catterall wrote: On 10/08/15 11:07, Tim Deegan wrote: This should happen in paging_fault() so it can guard the shadow-pagetable paths too. Once it's there, it'll need a check for is_hvm_vcpu() as well as for user_mode. Maybe have a helper function 'is_hvm_deprivileged_vcpu()' to do both checks, also used in hvm_deprivileged_check_trap() c. I've moved this and now need to add shadow page table support as this currently only supports HAP. Thanks. There shouldn't be very much work to do for this -- after all we're not running in the guest's pagetables so the actual shadow PT mechanism won't be needed. Maybe just a common helper function called from the shadow hap monitor-table builders? I wonder whether it would be better to switch to an IDT with all unacceptable traps stubbed out, rather than have to blacklist them all separately. Probably not - this check is cheap, and maintaining the parallel tables would be a pain. Or maybe there's some single point upstream of here, in the asm handlers, that would catch all the cases where this check is needed? Yep, I think this can be done. Had a deeper look at this. There is a point where all exceptions come in in the asm (handle_exception in entry.S) and we could branch out at this point. It does mean that we'd treat _all_ exceptions that occur in this mode the same way whereas the current way means that we can treat them differently (e.g. get __func__). So, should I make all exceptions go to the same point or keep as is? I think trap them all at the same point, unless you plan to have any exceptions that don't just kill the guest. I don't think you do, do you? This code is really Jan and Andrew's area, though. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v10 08/11] xen: arch-specific hooks for domain_soft_reset()
On 28.07.15 at 15:28, vkuzn...@redhat.com wrote:
x86-specific hook cleans up the pirq-emuirq mappings, destroys all ioreq
servers and and replaces the shared_info frame with an empty page to support
subsequent XENMAPSPACE_shared_info call.
ARM-specific hook is -ENOSYS for now.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Acked-by: Jan Beulich jbeul...@suse.com
with one minor remark:
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1066,6 +1066,13 @@ int domain_soft_reset(struct domain *d)
for_each_vcpu ( d, v )
unmap_vcpu_info(v);
+rc = arch_domain_soft_reset(d);
+if ( rc )
+{
+domain_crash(d);
+return rc;
+}
+
domain_resume(d);
return 0;
Perhaps better written as
rc = arch_domain_soft_reset(d);
if ( !rc )
domain_resume(d);
else
domain_crash(d);
return rc;
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 04/23] x86/boot: call reloc() using cdecl calling convention
On 20.07.15 at 16:28, daniel.ki...@oracle.com wrote: An empty description leaves us guess at the why. --- a/xen/arch/x86/boot/reloc.c +++ b/xen/arch/x86/boot/reloc.c @@ -10,15 +10,27 @@ *Keir Fraser k...@xen.org */ -/* entered with %eax = BOOT_TRAMPOLINE */ +/* + * This entry point is entered from xen/arch/x86/boot/head.S with: + * - 0x4(%esp) = BOOT_TRAMPOLINE_ADDRESS, + * - 0x8(%esp) = MULTIBOOT_INFORMATION_ADDRESS. + */ asm ( .text \n .globl _start \n _start: \n +push %ebp \n +mov %esp,%ebp\n What do you need this for? call 1f \n -1: pop %ebx \n -mov %eax,alloc-1b(%ebx) \n -jmp reloc\n +1: pop %ecx \n +mov 0x8(%ebp),%eax \n +mov %eax,alloc-1b(%ecx) \n +mov 0xc(%ebp),%eax \n +push %eax \n push 12(%ebp) +call reloc\n +add $4,%esp \n If you already copy %esp to %ebp at the top, mov %ebp, %esp would be the better alternative. +pop %ebp \n Or even just leave Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
From: Eric Dumazet eduma...@google.com On Mon, 2015-08-17 at 16:25 +0200, Sander Eikelenboom wrote: Monday, August 17, 2015, 4:21:47 PM, you wrote: On Mon, 2015-08-17 at 09:02 -0500, Jon Christopherson wrote: This is very similar to the behavior I am seeing in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=102911 OK, but have you applied the fix ? http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af It will be part of net iteration from David Miller to Linus Torvald. I did have that patch in for my last report. But i don't think he had (looking at the second part of his oops). Then can you try following fix as well ? Thanks ! [PATCH] timer: fix a race in __mod_timer() lock_timer_base() can not catch following : CPU1 ( in __mod_timer() timer-flags |= TIMER_MIGRATING; spin_unlock(base-lock); base = new_base; spin_lock(base-lock); timer-flags = ~TIMER_BASEMASK; CPU2 (in lock_timer_base()) see timer base is cpu0 base spin_lock_irqsave(base-lock, *flags); if (timer-flags == tf) return base; // oops, wrong base timer-flags |= base-cpu // too late We must write timer-flags in one go, otherwise we can fool other cpus. Fixes: bc7a34b8b9eb (timer: Reduce timer migration overhead if disabled) Signed-off-by: Eric Dumazet eduma...@google.com Cc: Thomas Gleixner t...@linutronix.de --- kernel/time/timer.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 5e097fa9faf7..84190f02b521 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -807,8 +807,8 @@ __mod_timer(struct timer_list *timer, unsigned long expires, spin_unlock(base-lock); base = new_base; spin_lock(base-lock); - timer-flags = ~TIMER_BASEMASK; - timer-flags |= base-cpu; + WRITE_ONCE(timer-flags, + (timer-flags ~TIMER_BASEMASK) | base-cpu); } } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode
At 14:53 +0100 on 17 Aug (1439823232), Ben Catterall wrote: On 12/08/15 14:33, Andrew Cooper wrote: On 12/08/15 14:29, Andrew Cooper wrote: On 11/08/15 19:29, Boris Ostrovsky wrote: Would switching TR only when we know that we need to enter this deprivileged mode help? This is an absolute must. It is not safe to use syscall/sysexit without IST in place for NMIs and MCEs. Assuming that it is less expensive than copying the stack. I was referring to the stack overflow issue, and whether it might be sensible to pro-actively which TR. Ahem! s/which/switch/ ~Andrew So, have we arrived at a decision for this? Thanks! Seems to have stalled a bit. OK, I propose that: - we use TR/IST to make Xen take interrupts/exceptions at a different SP; - we make that SP be an extension of the main stack, so that things like current() Just Work[tm]; - we set this up and tear it down when we enter/leave depriv mode. - someone ought to look at the case where IST handlers copy themselves to the main stack, and see if we need to adjust that too. Any other proposals? I think we can leave the question of TR switching on VMEXIT as a separate issue. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 3/4] HVM x86 deprivileged mode: Code for switching into/out of deprivileged mode
On 17.08.15 at 17:07, t...@xen.org wrote: At 14:53 +0100 on 17 Aug (1439823232), Ben Catterall wrote: So, have we arrived at a decision for this? Thanks! Seems to have stalled a bit. OK, I propose that: - we use TR/IST to make Xen take interrupts/exceptions at a different SP; - we make that SP be an extension of the main stack, so that things like current() Just Work[tm]; - we set this up and tear it down when we enter/leave depriv mode. - someone ought to look at the case where IST handlers copy themselves to the main stack, and see if we need to adjust that too. Any other proposals? No. I think we can leave the question of TR switching on VMEXIT as a separate issue. Just like for the other one - at this point I think anything that work should be okay. Dealing with quirks can be deferred (but it would be nice if a respective note was added in a prominent place so it doesn't get forgotten once/if these patches leave RFC state). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
On 14.08.15 at 16:59, shannon.z...@linaro.org wrote: 1. Copy and change some EFI and ACPI tables --- While some explanation on the reasons for this was given in the past discussion, I'm still missing a word on the why for each of these here. a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor, VendorGuid, VendorTable, ConfigurationTable. These changes are not very special and it just assign values to these members. I continue to question the need for fiddling with this table, not the least because I don't see how you intend to hand it to the Dom0 kernel: Are you expecting to call the kernel's ordinary EFI entry point, despite it not itself running on EFI firmware? b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and size information of Dom0. And Dom0 will get the memory information through this EFI table. To some degree the same applies here: While I see that you have no legacy vehicle like x86's E820, I also don't see how Dom0 - not being able to make EFI boot or runtime services calls - would get hold of this table. And if a non-EFI mechanism is to be used here, using the EFI data structure would turn out to be just an arbitrary (or convenience) decision, not something inherently required. Which I think should be said explicitly if so, rather than leaving the reader guess. c) Copy FADT table. Change the value of arm_boot_flags to enable PSCI and HVC. Let the hypervisor_id be XenVMM in order to tell Dom0 that it runs on Xen hypervisor, then Dom0 could through HVM_PARAM to get some informations for booting necessity, such as event-channel interrupt. Change header revison, length and checksum as well. d) Copy MADT table. According to the value of dom0_max_vcpus to change the number GICC entries. e) Create STAO table. This table is a new added one that's used to define a list of ACPI namespace names that are to be ignored by the OSPM in Dom0. Currently we use it to tell OSPM should ignore UART defined in SPCR table. f) Copy XSDT table. Add a new table entry for STAO and change other table's entries. g) Change the value of xsdt_physical_address in RSDP table. Which RSDP? Under EFI the table root is to be found from the EFI Configuration Table. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 05/23] x86/boot/reloc: create generic alloc and copy functions
On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote: Create generic alloc and copy functions. We need separate tools for memory allocation and copy to provide multiboot2 protocol support. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com --- v2 - suggestions/fixes: - generalize new functions names (suggested by Jan Beulich), - reduce number of casts (suggested by Jan Beulich). This contradicts retaining Andrew's R-b tag. Please remember to drop tags for everything you make non-trivial changes to. @@ -55,50 +56,64 @@ static void *reloc_mbi_struct(void *old, unsigned int bytes) sub %1,%0 \n and $~15,%0 \n mov %0,alloc-1b(%%edx) \n -mov %0,%%edi\n -rep movsb \n - : =r (new), +c (bytes), +S (old) - : : edx, edi, memory); -return new; + : =r (s) : r (bytes) : edx, memory); Can't bytes use a simple g constraint now? Preferably (i.e. if correct) this changed Acked-by: Jan Beulich jbeul...@suse.com Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 24/31] libxc: allow creating domains without emulated devices.
El 07/08/15 a les 18.36, Andrew Cooper ha escrit: On 07/08/15 11:18, Roger Pau Monne wrote: @@ -1336,7 +1343,8 @@ static int meminit_hvm(struct xc_dom_image *dom) * tot_pages will be target_pages - VGA_HOLE_SIZE after * this call. */ -rc = xc_domain_set_pod_target(xch, domid, target_pages - VGA_HOLE_SIZE, +rc = xc_domain_set_pod_target(xch, domid, target_pages - + dom-emulation ? VGA_HOLE_SIZE : 0, NULL, NULL, NULL); This might be more cleanly expressed as having d-vga_hole_size which is either VGA_HOLE_SIZE or 0, depending on dom-emulation. I'm afraid I don't understand this comment. What's d in the phrase above? I cannot see any local variable or argument called d in the context of meminit_hvm. Or do you mean that the dom-emulation flag should be split into dom-disable_ioreqs and dom-vga_hole_size? Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
On 17/08/2015 08:33, Jan Beulich wrote: On 14.08.15 at 16:59, shannon.z...@linaro.org wrote: 1. Copy and change some EFI and ACPI tables --- While some explanation on the reasons for this was given in the past discussion, I'm still missing a word on the why for each of these here. a) Copy EFI_SYSTEM_TABLE and change the value of FirmwareVendor, VendorGuid, VendorTable, ConfigurationTable. These changes are not very special and it just assign values to these members. I continue to question the need for fiddling with this table, not the least because I don't see how you intend to hand it to the Dom0 kernel: Are you expecting to call the kernel's ordinary EFI entry point, despite it not itself running on EFI firmware? b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and size information of Dom0. And Dom0 will get the memory information through this EFI table. To some degree the same applies here: While I see that you have no legacy vehicle like x86's E820, I also don't see how Dom0 - not being able to make EFI boot or runtime services calls - would get hold of this table. And if a non-EFI mechanism is to be used here, using the EFI data structure would turn out to be just an arbitrary (or convenience) decision, not something inherently required. Which I think should be said explicitly if so, rather than leaving the reader guess. It's not an arbitrary decision, when UEFI stub in Linux is using device tree properties to pass the UEFI table to the kernel ([1]). When booting on Xen with ACPI, dom0 will use the non-EFI entry point. The easiest way to pass the memory information to Linux is using the UEFI DT properties. Regards, [1] https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 4/4] HVM x86 deprivileged mode: Trap handlers for deprivileged mode
On 17.08.15 at 16:58, t...@xen.org wrote: At 14:59 +0100 on 17 Aug (1439823550), Ben Catterall wrote: On 11/08/15 11:33, Ben Catterall wrote: On 10/08/15 11:07, Tim Deegan wrote: I wonder whether it would be better to switch to an IDT with all unacceptable traps stubbed out, rather than have to blacklist them all separately. Probably not - this check is cheap, and maintaining the parallel tables would be a pain. Or maybe there's some single point upstream of here, in the asm handlers, that would catch all the cases where this check is needed? Yep, I think this can be done. Had a deeper look at this. There is a point where all exceptions come in in the asm (handle_exception in entry.S) and we could branch out at this point. It does mean that we'd treat _all_ exceptions that occur in this mode the same way whereas the current way means that we can treat them differently (e.g. get __func__). So, should I make all exceptions go to the same point or keep as is? I think trap them all at the same point, unless you plan to have any exceptions that don't just kill the guest. I don't think you do, do you? This code is really Jan and Andrew's area, though. And I think that deciding one way or the other here isn't necessary at this point in time. Once there is a clear picture of whether the route being explored here is actually usable, we can decide which one is the better model. For now I'd recommend using whatever is cheaper to implement. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 07/23] x86/boot/reloc: Rename some variables and rearrange code a bit
On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote: Rename mbi and mbi_old variables and rearrange code a bit to make it more readable. Additionally, this way multiboot (v1) protocol implementation and future multiboot2 protocol implementation will use the same variable naming convention. Signed-off-by: Daniel Kiper daniel.ki...@oracle.com Acked-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 18/22] xen/arm: ITS: Add domain specific ITS initialization
Hi Vijay,
This patch doesn't only do initialization but also destruction of vGIC info.
Although, a part of the domain initialization is done in part in #8 and
#8. It's very confusing to see the initialization split in 3 different
patch.
I would prefer to see the initialization/destruction in a single patch.
It would help to catch whether you forgot to see you forgot some bits.
On 27/07/2015 04:12, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Add Domain and vcpu specific ITS initialization
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
xen/arch/arm/vgic-v3-its.c| 10 ++
xen/arch/arm/vgic-v3.c| 10 ++
xen/arch/arm/vgic.c |3 +++
xen/include/asm-arm/gic-its.h |2 ++
xen/include/asm-arm/vgic.h|3 +++
5 files changed, 28 insertions(+)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 5323192..e182cee 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -44,6 +44,7 @@
#define GITS_PIDR4_VAL (0x04)
#define GITS_BASER_INIT_VAL ((1UL GITS_BASER_TYPE_SHIFT) | \
(0x7UL GITS_BASER_ENTRY_SIZE_SHIFT))
+//#define DEBUG_ITS
Why here?
#ifdef DEBUG_ITS
# define DPRINTK(fmt, args...) dprintk(XENLOG_DEBUG, fmt, ##args)
#else
@@ -1122,6 +1123,15 @@ int vits_domain_init(struct domain *d)
return 0;
}
+void vits_domain_free(struct domain *d)
+{
+ free_xenheap_pages(d-arch.vgic.vits-prop_page,
+ get_order_from_bytes(d-arch.vgic.vits-prop_size));
+ xfree(d-arch.vgic.pending_lpis);
+ xfree(d-arch.vgic.vits-collections);
+ xfree(d-arch.vgic.vits);
For instance, you add the initialization of these fields in patch #8 and
#10 but free everything here. I have to go in the others patch to get if
you forgot something or not.
+}
+
/*
* Local variables:
* mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 9e6e3ff..a09ba36 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1299,12 +1299,22 @@ static int vgic_v3_domain_init(struct domain *d)
d-arch.vgic.ctlr = VGICD_CTLR_DEFAULT;
+if ( is_hardware_domain(d) gic_lpi_supported() )
I think gic_lpi_supported is badly name. vITS should only be supported
when ITS is present, not when LPIs is present.
And I know that you unset LPIs when ITS is not present. But this confuse
the reader to do this.
+vits_domain_init(d);
+
return 0;
}
+void vgic_v3_domain_free(struct domain *d)
+{
+if ( is_hardware_domain(d) gic_lpi_supported() )
+vits_domain_free(d);
+}
+
static const struct vgic_ops v3_ops = {
.vcpu_init = vgic_v3_vcpu_init,
.domain_init = vgic_v3_domain_init,
+.domain_free = vgic_v3_domain_free,
.get_irq_priority = vgic_v3_get_irq_priority,
.get_target_vcpu = vgic_v3_get_target_vcpu,
.emulate_sysreg = vgic_v3_emulate_sysreg,
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 57c0f52..e2bfdb6 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -166,6 +166,9 @@ void domain_vgic_free(struct domain *d)
xfree(d-arch.vgic.shared_irqs);
xfree(d-arch.vgic.pending_irqs);
xfree(d-arch.vgic.allocated_irqs);
+
+if ( !d-arch.vgic.handler-domain_free )
The test is wrong. If domain_free is NULL you will end up to dereference
the pointer and crash.
+d-arch.vgic.handler-domain_free(d);
}
int vcpu_vgic_init(struct vcpu *v)
diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
index 870c9a8..da689a4 100644
--- a/xen/include/asm-arm/gic-its.h
+++ b/xen/include/asm-arm/gic-its.h
@@ -367,6 +367,8 @@ int its_cpu_init(void);
void its_set_lpi_properties(struct irq_desc *desc,
const cpumask_t *cpu_mask,
unsigned int priority);
+int vits_domain_init(struct domain *d);
+void vits_domain_free(struct domain *d);
int vits_get_vitt_entry(struct domain *d, uint32_t devid,
uint32_t event, struct vitt *entry);
int vits_get_vdevice_entry(struct domain *d, uint32_t devid,
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index b11faa0..853df04 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -114,6 +114,8 @@ struct vgic_ops {
int (*vcpu_init)(struct vcpu *v);
/* Domain specific initialization of vGIC */
int (*domain_init)(struct domain *d);
+/* Free domain specific resources */
+void (*domain_free)(struct domain *d);
/* Get priority for a given irq stored in vgic structure */
int (*get_irq_priority)(struct vcpu *v, unsigned int irq);
/* Get the target vcpu for a given virq. The rank lock is already taken
@@ -191,6 +193,7 @@ enum gic_sgi_mode;
#define vgic_num_irqs(d)((d)-arch.vgic.nr_spis + 32)
extern int
[Xen-devel] [PATCH for-4.6 v3 0/3] More vNUMA fixes
Wei Liu (3): xl: fix vNUMA vdistance parsing xl: error out if vNUMA specifies more vcpus than pcpus libxc: fix vNUMA memory allocation tools/libxc/xc_hvm_build_x86.c | 6 -- tools/libxl/xl_cmdimpl.c | 34 +- 2 files changed, 33 insertions(+), 7 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.6 v3 3/3] libxc: fix vNUMA memory allocation
Only 4KB allocation was using new_memflags. We should use new_memflags
in for 2MB and 1GB allocation as well because that variable contains
node information.
Without this patch, when creating a HVM guest with vNUMA, because the
node information was not present in the flags passed to libxc, actual
memory allocation didn't comply with what user specified. With this
patch the behaviour is correct.
Reported-by: Boris Ostrovsky boris.ostrov...@oracle.com
Tested-by: Boris Ostrovsky boris.ostrov...@oracle.com
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Dario Faggioli dario.faggi...@citrix.com
---
v3: better commit message
---
tools/libxc/xc_hvm_build_x86.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tools/libxc/xc_hvm_build_x86.c b/tools/libxc/xc_hvm_build_x86.c
index ec11f15..ea250dd 100644
--- a/tools/libxc/xc_hvm_build_x86.c
+++ b/tools/libxc/xc_hvm_build_x86.c
@@ -486,7 +486,8 @@ static int setup_guest(xc_interface *xch,
done = xc_domain_populate_physmap(xch, dom, nr_extents,
SUPERPAGE_1GB_SHIFT,
- memflags, sp_extents);
+ new_memflags,
+ sp_extents);
if ( done 0 )
{
@@ -526,7 +527,8 @@ static int setup_guest(xc_interface *xch,
done = xc_domain_populate_physmap(xch, dom, nr_extents,
SUPERPAGE_2MB_SHIFT,
- memflags, sp_extents);
+ new_memflags,
+ sp_extents);
if ( done 0 )
{
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.6 v3 1/3] xl: fix vNUMA vdistance parsing
We should parse the output from splitting function, not the original
string, otherwise the parsed result is wrong.
For example:
vnuma = [ [...,vdistance=10,20,...],
[...,vdistance=20,10,...] ]
Before this change, vdistance from node 0 to all nodes (including
itself) was 10 and vdistance from node 1 to all nodes was 20.
After this change, vdistance from node 0 to itself is 10, to node 1 is
20 and vdistance from node 1 to node 0 is 20, to itself is 10. That's
the correct vdistance settings we expect.
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Dario Faggioli dario.faggi...@citrix.com
---
v3: better commit message
---
tools/libxl/xl_cmdimpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c6b0b68..44fff82 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1188,7 +1188,7 @@ static void parse_vnuma_config(const XLU_Config *config,
len = libxl_string_list_length(vdist);
for (j = 0; j len; j++) {
-val = parse_ulong(value);
+val = parse_ulong(vdist[j]);
p-distances[j] = val;
}
libxl_string_list_dispose(vdist);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH for-4.6 v3 2/3] xl: error out if vNUMA specifies more vcpus than pcpus
... but allow user to override that check by specifying maxvcpus= in xl
configuration file.
Note that the code is constructed such that the fallout is dealt with
after parsing. We can live with that because though it wastes a bit of
cpu cycles but it is still functionally correct and I would like to have
a clear split between parsing and dealing with fallouts.
Signed-off-by: Wei Liu wei.l...@citrix.com
Reviewed-by: Dario Faggioli dario.faggi...@citrix.com
---
tools/libxl/xl_cmdimpl.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 44fff82..ebbb9a5 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1175,6 +1175,14 @@ static void parse_vnuma_config(const XLU_Config *config,
for (j = 0; j len; j++) {
parse_range(cpu_spec_list[j], s, e);
for (; s = e; s++) {
+/*
+ * Note that if we try to set a bit beyond
+ * the size of bitmap, libxl_bitmap_set
+ * has no effect. The resulted bitmap
+ * doesn't reflect what user wants. The
+ * fallout is dealt with later after
+ * parsing.
+ */
libxl_bitmap_set(vcpu_parsed[i], s);
max_vcpus++;
}
@@ -1202,11 +1210,27 @@ static void parse_vnuma_config(const XLU_Config *config,
}
/* User has specified maxvcpus= */
-if (b_info-max_vcpus != 0 b_info-max_vcpus != max_vcpus) {
-fprintf(stderr, xl: vnuma vcpus and maxvcpus= mismatch\n);
-exit(1);
-} else
+if (b_info-max_vcpus != 0) {
+if (b_info-max_vcpus != max_vcpus) {
+fprintf(stderr, xl: vnuma vcpus and maxvcpus= mismatch\n);
+exit(1);
+}
+} else {
+int host_cpus = libxl_get_online_cpus(ctx);
+
+if (host_cpus 0) {
+fprintf(stderr, Failed to get online cpus\n);
+exit(1);
+}
+
+if (host_cpus max_vcpus) {
+fprintf(stderr, xl: vnuma specifies more vcpus than pcpus, \
+use maxvcpus= to override this check.\n);
+exit(1);
+}
+
b_info-max_vcpus = max_vcpus;
+}
/* User has specified maxmem= */
if (b_info-max_memkb != LIBXL_MEMKB_DEFAULT
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [URGENT RFC] Branching and reopening -unstable
Hi Wei, Thanks for CCing me, for me, I prefer option 2, it won't affect the normal development release cycle, if the contributor wants to contribute to -unstable, then it is his responsibility to resolve the confilicts on the main branch. but I think it depends on the maintainers who will make the decision. On 08/11/2015 08:31 PM, Wei Liu wrote: CCing Hongyang, I missed him when I copy-n-paste emails from MAINTAINERS. On Tue, Aug 11, 2015 at 11:44:07AM +0100, Wei Liu wrote: Hi all RC1 is going to be tagged this week (maybe today). We need to figure out when to branch / reopen -unstable for committing and what rules should be applied until 4.6 is out of the door. Ian, Ian and I had a conversation IRL. We discussed several things, but figured it is necessary to have more people involved before making any decision. Here is my recollection of the conversation. Branching should be done at one of the RC tags. It might not be enough time for us to reach consensus before tagging RC1, so I would say lets branch at RC2 if we don't observe blocker bugs. Maintainers should be responsible for both 4.6 branch and -unstable branch. As for bug fixes, here are two options. Option 1: bug fixes go into -unstable, backport / cherry-pick bug fixes back to 4.6. This seems to leave the tree in half frozen status because we need to reject refactoring patches in case they cause backporting failure. Option 2: bug fixes go into 4.6, merge them to -unstable. If merge has conflict and maintainers can't deal with that, the authors of those changes in -unstable which cause conflict is responsible for fixing up the conflict. Ian and Ian, anything I miss? Anything to add? Others, thoughts? Wei. . -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: arm: Set all bits in mfn_to_xen_entry()
Hi Chris, On 14/08/2015 14:42, Chris (Christopher) Brand wrote: Ensure that every bit has a specific value. Reported-by: Julien Grall julien.gr...@citrix.com Signed-off-by: Chris Brand chris.br...@broadcom.com --- xen/include/asm-arm/page.h | 5 + 1 file changed, 5 insertions(+) diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h index 01628f3e96cb..7a56b2cb463a 100644 --- a/xen/include/asm-arm/page.h +++ b/xen/include/asm-arm/page.h @@ -202,9 +202,14 @@ static inline lpae_t mfn_to_xen_entry(unsigned long mfn, unsigned attr) .ai = attr, .ns = 1, /* Hyp mode is in the non-secure world */ .user = 1,/* See below */ +.ro = 0, /* Assume read-write */ .af = 1, /* No need for access tracking */ .ng = 1, /* Makes TLB flushes easier */ +.sbz = 0, +.contig = 0, /* Assume non-contiguous */ +.pxn = 0, I would add a comment to explain that this bit is reserved for PL2 stage 1 page table. .xn = 1, /* No need to execute outside .text */ +.avail = 0, I don't think this one is necessary. avail is not used by the hardware neither Xen. }};; what about *t fields (pxnt, xnt, apt,...)? /* Setting the User bit is strange, but the ATS1H[RW] instructions * don't seem to work otherwise, and since we never run on Xen Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: arm: Set all bits in mfn_to_xen_entry()
On 17/08/2015 11:58, Chris (Christopher) Brand wrote: Hi Julien, Thanks for the review. +.pxn = 0, I would add a comment to explain that this bit is reserved for PL2 stage 1 page table. Will do. +.avail = 0, I don't think this one is necessary. avail is not used by the hardware neither Xen. grep -rF pt.avail xen gives 7 matches in xen/arch/arm/mm.c, so it is used by Xen (I'll fully admit that I didn't dig in to the how and why of its use). Hmmm right. Sorry I haven't check the Xen code for that. It's used for domheap mapping to know how many times it has been referenced. what about *t fields (pxnt, xnt, apt,...)? I figured that as we're setting table to 0, these are ignored, and any code setting table to 1 should then set them. I can obviously easily set them here (I guess all to zero would make sense) if you think it's worthwhile ... It was just an open question. :) I'm not sure what we should do with them. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] xen: arm: Ensure all PTE bits have a known value
On 14/08/2015 14:41, Chris (Christopher) Brand wrote: Hi, Hi Chris, Thank you for the patch. This is more-or-less what Julien requested. He noted that pt.contig was never set to zero. When I looked further, I found other bits that were also never given a value. Looking at the callsites, they almost all seem to assume a value of zero, so that's what I went with. Patch 1 re-orders the assignments to match the declaration, making it clearer which ones are missing. Patch 2 then adds the missing bits. Chris P.S. Apologies for any threading issues - I have not yet managed to get git send-email working properly. I'm usually using git format-patch to get a list of files (one per patch) and my cover letter (--cover-letter). Then I use git send-email *.patch which will send the patch correctly threading. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 17/22] xen/arm: ITS: Initialize physical ITS
Hi Vijay,
On 27/07/2015 04:11, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Initialize physical ITS driver from GIC v3 driver
if LPIs are supported by hardware
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v5: Made check of its dt node availability before
setting lpi_supported flag
---
xen/arch/arm/gic-v3.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 8c7c5cf..23eb47c 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -714,6 +714,10 @@ static int __cpuinit gicv3_cpu_init(void)
if ( gicv3_enable_redist() )
return -ENODEV;
+/* Give LPIs a spin */
+if ( gicv3_info.lpi_supported )
+its_cpu_init();
+
/* Set priority on PPI and SGI interrupts */
priority = (GIC_PRI_IPI 24 | GIC_PRI_IPI 16 | GIC_PRI_IPI 8 |
GIC_PRI_IPI);
@@ -1323,11 +1327,18 @@ static int __init gicv3_init(void)
if ( gicv3_dist_supports_lpis() )
{
-gicv3_info.lpi_supported = 1;
-gicv3_info.nr_event_ids = its_get_nr_event_ids();
+/*
+ * LPI support is enabled only if HW supports it and
+ * ITS dt node is available
+ */
+if ( !its_init(gicv3.rdist_data) )
+{
+gicv3_info.lpi_supported = 1;
+gicv3_info.nr_event_ids = its_get_nr_event_ids();
+}
+else
+gicv3_info.lpi_supported = 0;
I think this is wrong to use LPI supported to know whether ITS is
present or not.
AFAICT, most the usage of lpi_supported is only for vgic where you
should have a proper field in the vgic structure rather than using this
field.
For the rest, we may want to support LPIs without ITS at some point. So
we should keep 2 distincts field for this purpose. Although, I believe
that we can drop most of them.
}
-else
-gicv3_info.lpi_supported = 0;
Why did you drop the else? It was valid...
gicv3_dist_init();
res = gicv3_cpu_init();
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] xen: arm re-order assignments in mfn_to_xen_entry()
Hi Chris, On 14/08/2015 14:41, Chris (Christopher) Brand wrote: Shuffle lines around so that the assignments in mfn_to_xen_entry() occur in the same order as the bits are declared in lpae_pt_t. This makes it easier to see which ones are never given a value. No change in behaviour. Also fix a minor comment typo. Signed-off-by: Chris Brand chris.br...@broadcom.com Reviewed-by: Julien Grall julien.gr...@citrix.com Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On 2015-08-17 19:18, Eric Dumazet wrote: From: Eric Dumazet eduma...@google.com On Mon, 2015-08-17 at 16:25 +0200, Sander Eikelenboom wrote: Monday, August 17, 2015, 4:21:47 PM, you wrote: On Mon, 2015-08-17 at 09:02 -0500, Jon Christopherson wrote: This is very similar to the behavior I am seeing in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=102911 OK, but have you applied the fix ? http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af It will be part of net iteration from David Miller to Linus Torvald. I did have that patch in for my last report. But i don't think he had (looking at the second part of his oops). Then can you try following fix as well ? Thanks ! Running now :) [PATCH] timer: fix a race in __mod_timer() lock_timer_base() can not catch following : CPU1 ( in __mod_timer() timer-flags |= TIMER_MIGRATING; spin_unlock(base-lock); base = new_base; spin_lock(base-lock); timer-flags = ~TIMER_BASEMASK; CPU2 (in lock_timer_base()) see timer base is cpu0 base spin_lock_irqsave(base-lock, *flags); if (timer-flags == tf) return base; // oops, wrong base timer-flags |= base-cpu // too late We must write timer-flags in one go, otherwise we can fool other cpus. Fixes: bc7a34b8b9eb (timer: Reduce timer migration overhead if disabled) Signed-off-by: Eric Dumazet eduma...@google.com Cc: Thomas Gleixner t...@linutronix.de --- kernel/time/timer.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 5e097fa9faf7..84190f02b521 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -807,8 +807,8 @@ __mod_timer(struct timer_list *timer, unsigned long expires, spin_unlock(base-lock); base = new_base; spin_lock(base-lock); - timer-flags = ~TIMER_BASEMASK; - timer-flags |= base-cpu; + WRITE_ONCE(timer-flags, + (timer-flags ~TIMER_BASEMASK) | base-cpu); } } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH for-4.6 v2 2/3] xl: error out if vNUMA specifies more vcpus than pcpus
On Sun, Aug 16, 2015 at 09:51:53AM +0100, Ian Campbell wrote: On Fri, 2015-08-14 at 00:38 +0100, Wei Liu wrote: In fact, if b_info-max_vcpus is 0, the elements of vcpu_parsed are sized against the host pcpus, and we risk to call libxl_bitmap_set() for vcpus beyond that limit, while parsing the vcpus subsection of the vnode specification (which happens _before_ this check). Or am I missing something? That's fine because that function has no effect when you try to set a bit beyond its size. This sort of subtlety is worthy of a comment in either the code of the commit message. Assuming I'm not, it seems to me that a solution could be to check for this situation _inside_ the 'else if (!strcmp(vcpus, option))'. In fact, if maxvcpus has not been specified, as soon as the end of one of the ranges --as returned by parse_range()-- is beyond host_cpus, we know we'd be going past the limit of the corresponding element of vcpu_parsed, and we can error out. FWIW that's what I was expecting to happen... It'll most likely be a bit uglier than this patch, but probably still less complex than v1. :-) That doesn't make any difference in terms of functionality. I would rather leave the parsing bit as it is and deal with fallout separately. That would make code cleaner IMHO. ... It's a bit wasteful to keep parsing after things have already failed, but I suppose that's not too bad and we can live with it. I will add comments and resend. Wei. Ian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] xen: arm: Set all bits in mfn_to_xen_entry()
Hi Julien, Thanks for the review. +.pxn = 0, I would add a comment to explain that this bit is reserved for PL2 stage 1 page table. Will do. +.avail = 0, I don't think this one is necessary. avail is not used by the hardware neither Xen. grep -rF pt.avail xen gives 7 matches in xen/arch/arm/mm.c, so it is used by Xen (I'll fully admit that I didn't dig in to the how and why of its use). what about *t fields (pxnt, xnt, apt,...)? I figured that as we're setting table to 0, these are ignored, and any code setting table to 1 should then set them. I can obviously easily set them here (I guess all to zero would make sense) if you think it's worthwhile ... Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] xen: arm: Ensure all PTE bits have a known value
P.S. Apologies for any threading issues - I have not yet managed to get git send-email working properly. I'm usually using git format-patch to get a list of files (one per patch) and my cover letter (--cover-letter). Thanks. Then I use git send-email *.patch which will send the patch correctly threading. Yeah, the difficulty is finding the right set of --smtp* options to get it through our corporate mail server. I had it working once upon a time when I was working for Linaro, but something somewhere seems to have changed :-) Chris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 20/22] xen/arm: ITS: Map ITS translation space
Hi Vijay,
On 27/07/2015 04:12, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
ITS translation space contains GITS_TRANSLATOR register
which is written by device to raise LPI. This space needs
to mapped to every domain address space for all physical
ITS available,so that device can access GITS_TRANSLATOR
register using SMMU.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/vgic-v3-its.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index e182cee..27523f4 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -1060,6 +1060,42 @@ static const struct mmio_handler_ops
vgic_gits_mmio_handler = {
.write_handler = vgic_v3_gits_mmio_write,
};
+/*
+ * Map the 64K ITS translation space in guest.
+ * This is required purely for device smmu writes.
+*/
+
+static int vits_map_translation_space(struct domain *d)
+{
+uint64_t addr, size;
+int ret;
+
+if ( !is_hardware_domain(d) )
Well this code is surely wrong. If you happen to have a guest domain,
you won't map anything and say you've done it.
Given that vits_domain_init is only called for DOM0, you should drop
this check.
+return 0;
+
+ASSERT(is_domain_direct_mapped(d));
+
+addr = d-arch.vgic.vits-gits_base + SZ_64K;
+size = SZ_64K;
+
+/* Using 1:1 mapping to map translation space */
+/* TODO: Handle DomU mapping */
+ret = map_mmio_regions(d,
+ paddr_to_pfn(addr PAGE_MASK),
+ DIV_ROUND_UP(size, PAGE_SIZE),
+ paddr_to_pfn(addr PAGE_MASK));
+
+if ( ret )
+{
+ dprintk(XENLOG_G_ERR, vITS: Unable to map to dom%d access to
+ 0x%PRIx64 - 0x%PRIx64\n,
Unable to map 0x...-0x... to dom%d
+ d-domain_id,
+ addr PAGE_MASK, PAGE_ALIGN(addr + size) - 1);
+}
+
+return ret;
+}
+
int vits_domain_init(struct domain *d)
{
struct vgic_its *vits;
@@ -1120,7 +1156,7 @@ int vits_domain_init(struct domain *d)
register_mmio_handler(d, vgic_gits_mmio_handler, vits-gits_base,
SZ_64K);
-return 0;
+return vits_map_translation_space(d);
}
void vits_domain_free(struct domain *d)
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 19/22] xen/arm: ITS: Add APIs to add and assign device
Hi Vijay,
On 27/07/2015 04:12, vijay.kil...@gmail.com wrote:
+for ( i = 0; i dev-nr_lpis; i++ )
+{
+msi = xzalloc(struct msi_desc);
+/* Reserve pLPI */
+if ( its_alloc_device_irq(dev, plpi) || !msi )
+{
+its_discard_lpis(dev, i);
+its_lpi_free(dev);
+its_send_mapd(dev, 0);
+its_free_device(dev);
+dprintk(XENLOG_G_ERR,ITS: Cannot add device 0x%PRIx32\n,
devid);
+res = -ENOSPC;
+goto err;
+}
+
+/* For each pLPI send MAPVI command */
+col = dev-its-collections[(i % nr_cpu_ids)];
+/* Store collection for this plpi in irq_desc */
+desc = irq_to_desc(plpi);
+spin_lock(desc-lock);
+desc-msi_desc = msi;
It's rather strange to directly use msi_desc field here when you
introduced helper for all the other fields.
As I said on a previous mail, I would prefer to see an helper to set the
msi_desc and avoid introducing ITS specific helpers for all the other
fields in irq.c.
+set_lpi_event(desc, i);
+set_irq_its_device(desc, dev);
+irqdesc_set_collection(desc, col-col_id);
Please be consistent with the name. 3 helpers doing the same (setting
fields in MSI), 3 completely different naming...
+spin_unlock(desc-lock);
+its_send_mapvi(dev, col, plpi, i);
+}
+
+err:
+spin_unlock(rb_its_dev_lock);
+
+return res;
+}
+
+int its_assign_device(struct domain *d, u32 vdevid, u32 pdevid)
+{
+struct its_device *pdev;
+u32 plpi, i;
+
+DPRINTK(ITS: Assign request for dev 0x%PRIx32 to domain %PRId32\n,
+vdevid, d-domain_id);
+
+spin_lock(rb_its_dev_lock);
+pdev = its_find_device(pdevid);
+if ( !pdev )
+{
+spin_unlock(rb_its_dev_lock);
+return -ENODEV;
+}
+spin_unlock(rb_its_dev_lock);
+
+pdev-domain_id = d-domain_id;
+pdev-virt_device_id = vdevid;
+
+DPRINTK(ITS: Assign pdevid 0x%PRIx32 lpis %PRId32 for dom
%PRId32\n,
+pdevid, pdev-nr_lpis, d-domain_id);
+
+for ( i = 0; i pdev-nr_lpis; i++ )
+{
+plpi = its_get_plpi(pdev, i);
+/* TODO: Route lpi */
Seriously? Why did you drop the code since v4 here?
We are at v5, I'm expecting to see this series working if I'm applying
to my tree. Without the routing, I don't see how PCI can work with ITS
on DOM0... You didn't even mention it in the cover letter!
You should test your series without any additional patch on upstream Xen
before sending it.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
On Mon, 17 Aug 2015, Eric Dumazet wrote: [PATCH] timer: fix a race in __mod_timer() lock_timer_base() can not catch following : CPU1 ( in __mod_timer() timer-flags |= TIMER_MIGRATING; spin_unlock(base-lock); base = new_base; spin_lock(base-lock); timer-flags = ~TIMER_BASEMASK; CPU2 (in lock_timer_base()) see timer base is cpu0 base spin_lock_irqsave(base-lock, *flags); if (timer-flags == tf) return base; // oops, wrong base timer-flags |= base-cpu // too late We must write timer-flags in one go, otherwise we can fool other cpus. Fixes: bc7a34b8b9eb (timer: Reduce timer migration overhead if disabled) Signed-off-by: Eric Dumazet eduma...@google.com Cc: Thomas Gleixner t...@linutronix.de --- kernel/time/timer.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 5e097fa9faf7..84190f02b521 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -807,8 +807,8 @@ __mod_timer(struct timer_list *timer, unsigned long expires, spin_unlock(base-lock); base = new_base; spin_lock(base-lock); - timer-flags = ~TIMER_BASEMASK; - timer-flags |= base-cpu; + WRITE_ONCE(timer-flags, +(timer-flags ~TIMER_BASEMASK) | base-cpu); Duh, yes. Picking it up for timers/urgent. Thanks for spotting it. tglx ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Could Xen hyperviosr be able to invoke Linux systemcalls?
On Mon, 2015-08-17 at 00:55 +, Kun Cheng wrote: On Mon, Aug 17, 2015 at 12:16 AM Frediano Ziglio fredd...@gmail.com What I'm planing is adding page migration support for NUMA aware scheduling. In such a case the most time I'll be dealing with Xen's memory management scheduling part to make relevant pages migrate to another node with their VCPU. However, Linux kernel has already implemented some basic mechanisms so the whole work would be better by leveraging the kernel's existing code or functions. No, not at all. As you figured (or at least had intuition about) yourself, Xen does run below Linux. Actually, it runs below any guest, including Dom0, which is a special guest but still a guest, and can even not be a Linux guest. So there's no code sharing, or no mechanism to invoke Linux code and have it affect Xen's scheduling or memory management (and never will be :-P). More specifically, I want to confirm that could we use the code or functions in linux kernel to assist the hypervisor? No, it's the other way around. My guess is not because in my understanding xen hypervisor lies under the linux kernel, i.e. dom0's kernel. Exactly. Given that Dom0 is a special domain, if I want to manage move all the machine memory pages, can the kernel be helpful? The Dom0 kernel doesn't know anything about the memory of other guest. It basically doesn't even know that they exist... That's the point of virtualization, isn't it? Also Linux's and Xen's scheduling and memory management are so different (and that's by design) that, even for similar (or the same) feature, the implementation will be different anyway, so sharing the code won't help at all. Hmm, change the memory from dom0 means we can control the VM's memory by using a config file or xl command right? changing the memory from dom0 means something like the dom0 can ask Xen, via toolstack, to do something to the memory of other guests, i.e., it has enough privileges to do that, but that's it. What if we goes to the code level? I'm really confused now. Is Xen's memory management complemented all by itsself or does it also receive help from the kernel? As said, Xen doesn't even know what kernel is actually running in the various guest, including dom0, and things should remains that way, especially for core things like scheduling and memory management. So, in summary, what you're after should be achieved entirely inside Xen. It is possible than, in the PV guest case, you'd need some help from the guest. However, that would be in the form of Xen asking/forcing the guest to do something on the *guest* *itself*, not in the form of Xen asking dom0 to do something on Xen's own memory/scheduling or (directly) on other guests' memory. Hope this helps clearing things out for you. :-) Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 21/22] xen/arm: ITS: Generate ITS node for Dom0
On 27/07/2015 04:12, vijay.kil...@gmail.com wrote:
From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
Parse host dt and generate ITS node for Dom0.
ITS node resides inside GIC node so when GIC node
is encountered look for ITS node.
Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
---
v5: - Moved ITS dt node generation to ITS driver
v4: - Generate only one ITS node for Dom0
- Replace msi-parent references to single its phandle
---
xen/arch/arm/domain_build.c | 17 ++
xen/arch/arm/gic-v3-its.c | 74 +
xen/arch/arm/gic-v3.c | 29
xen/arch/arm/gic.c| 18 ++
xen/include/asm-arm/gic-its.h |3 ++
xen/include/asm-arm/gic.h |7
6 files changed, 148 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 8556afd..6b6f013 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -469,6 +469,19 @@ static int write_properties(struct domain *d, struct
kernel_info *kinfo,
continue;
}
+/*
+ * Replace all msi-parent phandle references to single ITS node
+ * generated for Dom0
+ */
+if ( dt_property_name_is_equal(prop, msi-parent) )
I think this need more care than replacing every msi-parent without any
checking.
You need to make sure that the msi-parent points to an ITS MSI just in
case there is other possibility of MSI.
Furthermore, I would do this a ITS specific callback (gic_rewrite_node
or smth similar) to avoid replacing msi-parent when it's not necessary.
I have in mind GICv2M.
+{
+fdt32_t phandle = gic_get_msi_handle();
+DPRINT( Set msi-parent(ITS) phandle 0x%x\n,phandle);
+fdt_property(kinfo-fdt, prop-name, (void *)phandle,
+ sizeof(phandle));
+continue;
+}
+
res = fdt_property(kinfo-fdt, prop-name, prop_data, prop_len);
xfree(new_data);
@@ -875,6 +888,10 @@ static int make_gic_node(const struct domain *d, void *fdt,
return res;
res = fdt_end_node(fdt);
+if ( res )
+return res;
+
+res = gic_its_hwdom_dt_node(d, node, fdt);
Can you explain why you didn't follow my suggestion to plumb the ITS
node creation in gic_hwdow_dt_node? IHMO there is no need of new callback.
Furthermore the call is misplaced. You will end up to have a DT looking like
gic {
}
gic-its {
}
rather than
gic {
gic-its {
}
}
return res;
}
diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 99f6edc..042c70d 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
+int its_make_dt_node(const struct domain *d,
+ const struct dt_device_node *node, void *fdt)
+{
+struct its_node *its;
+const struct dt_device_node *gic;
+const void *compatible = NULL;
+u32 len;
+__be32 *new_cells, *tmp;
+int res = 0;
+
+/* Will pass only first ITS node info */
+its = list_first_entry(its_nodes, struct its_node, entry);
+if ( !its )
+{
+dprintk(XENLOG_ERR, ITS node not found\n);
+return -FDT_ERR_XEN(ENOENT);
+}
+
+gic = its-dt_node;
+
+compatible = dt_get_property(gic, compatible, len);
+if ( !compatible )
+{
+dprintk(XENLOG_ERR, Can't find compatible property for the its
node\n);
+return -FDT_ERR_XEN(ENOENT);
+}
+
+res = fdt_begin_node(fdt, gic-its);
+if ( res )
+return res;
+
+res = fdt_property(fdt, compatible, compatible, len);
+if ( res )
+return res;
+
+res = fdt_property(fdt, msi-controller, NULL, 0);
+if ( res )
+return res;
+
+len = dt_cells_to_size(dt_n_addr_cells(node) + dt_n_size_cells(node));
+
+new_cells = xzalloc_bytes(len);
+if ( new_cells == NULL )
+return -FDT_ERR_XEN(ENOMEM);
+tmp = new_cells;
+
+dt_set_range(tmp, node, its-phys_base, its-phys_size);
+
+res = fdt_property(fdt, reg, new_cells, len);
+xfree(new_cells);
+
+if ( node-phandle )
+{
+res = fdt_property_cell(fdt, phandle, node-phandle);
+if ( res )
+return res;
+
+its_phandle = cpu_to_fdt32(node-phandle);
Why this is set in make_hwdom_dt_node? The ITS phandle may be used
before we effectively parse the GIC node.
+}
+
+res = fdt_end_node(fdt);
+
+return res;
+}
+
+
+fdt32_t its_get_lpi_handle(void)
+{
+return its_phandle;
+}
+
static int its_force_quiescent(void __iomem *base)
{
u32 count = 100; /* 1s */
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 23eb47c..828bf27 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1143,6 +1143,34 @@ static int gicv3_make_hwdom_dt_node(const struct domain
*d,
return res;
}
+static int gicv3_make_hwdom_its_dt_node(const struct domain *d,
+
Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 3
Hi,
On 17/08/2015 06:01, Shannon Zhao wrote:
On 2015/8/14 23:17, Julien Grall wrote:
On 14/08/15 15:59, Shannon Zhao wrote:
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and size of uefi system table, address and size
of uefi memory table, uefi-mmap-desc-size and uefi-mmap-desc-ver.
An example of the minimal DT:
/ {
#address-cells = 2;
#size-cells = 1;
chosen {
bootargs = kernel=Image console=hvc0 earlycon=pl011,0x1c09
root=/dev/vda2 rw rootfstype=ext4 init=/bin/sh acpi=force;
linux,initrd-start = 0x;
linux,initrd-end = 0x;
linux,uefi-system-table = 0x;
linux,uefi-mmap-start = 0x;
linux,uefi-mmap-size = 0x;
linux,uefi-mmap-desc-size = 0x;
linux,uefi-mmap-desc-ver = 0x;
};
};
For details loook at
https://github.com/torvalds/linux/blob/master/Documentation/arm/uefi.txt
I would have expect a summary on the discussion we had on the previous
thread [1].
Note that linux,initrd-* are well defined given that Xen, U-boot and
other bootloaders are using them. And IIRC, it's Linux specific.
Although, linux,uefi-* are not well defined (only used internally by
Linux betwen the EFI stub and the kernel) and we expect other OS to use
them in the future.
So I would prefer to the linux, dropped for them.
Yes, I think it's good to drop the linux, too. But if we drop the
linux, would it impact the linux kernel booting with UEFI? And why we
don't do it to Xen since Xen still uses linux,?
I don't understand your second question.
For the first question, as we discussed in several mail, the property
linux,uefi-* are only used internally between the stub and Linux. The
sub is compiled in the kernel so there is no issue to change the property.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 21/23] x86/boot: implement early command line parser in C
On Sun, Aug 16, 2015 at 01:22:05PM -0400, Konrad Rzeszutek Wilk wrote: On August 16, 2015 9:48:05 AM EDT, George Diamantopoulos georged...@gmail.com wrote: Hello, I've been trying to compile xen with multiboot2 support, but building has been failing. Tried with both gcc-4.8.4 and gcc-5.2 on ivybridge and amdfam10h, same results. CCing Daniel who has been troubleshooting that. It is compiler tools related and with older compilers it works. New GCC calculates jump address for C switch/case using .rodata section. The simplest solution/workaround seems change to series of ifs but not nice. I must think about better fix for this issue. Daniel ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 60706: regressions - FAIL
flight 60706 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/60706/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 30511 Tests which are failing intermittently (not blocking): test-amd64-i386-rumpuserxen-i386 2 hosts-allocate broken in 60224 pass in 60706 test-amd64-amd64-rumpuserxen-amd64 2 hosts-allocate broken in 60224 pass in 60706 test-amd64-i386-xl-qemuu-win7-amd64 2 hosts-allocate broken in 60224 pass in 60706 test-amd64-i386-xl-qemut-win7-amd64 2 hosts-allocate broken in 60224 pass in 60706 test-amd64-amd64-xl-sedf-pin 6 xen-boot fail in 58831 pass in 58798 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 58831 pass in 60706 test-amd64-i386-pair 10 xen-boot/dst_host fail pass in 58831 test-amd64-i386-pair 9 xen-boot/src_host fail pass in 58831 test-amd64-amd64-xl 6 xen-bootfail pass in 59576 test-amd64-amd64-pair10 xen-boot/dst_host fail pass in 59961 test-amd64-amd64-libvirt 6 xen-bootfail pass in 60064 test-amd64-amd64-pair 9 xen-boot/src_host fail pass in 60224 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt-qcow2 2 hosts-allocate broken in 60224 baseline untested test-amd64-amd64-libvirt-raw 2 hosts-allocate broken in 60224 baseline untested test-amd64-amd64-libvirt-vhd 2 hosts-allocate broken in 60224 baseline untested test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-i386-xl-xsm6 xen-bootfail baseline untested test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-multivcpu 6 xen-boot fail baseline untested test-amd64-i386-libvirt-xsm 6 xen-bootfail baseline untested test-amd64-amd64-xl-xsm 6 xen-bootfail baseline untested test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-amd64-amd64-xl-credit2 6 xen-bootfail baseline untested test-amd64-amd64-xl-rtds 6 xen-bootfail baseline untested test-amd64-amd64-libvirt-qcow2 6 xen-boot fail baseline untested test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail baseline untested test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 guest-start/debianhvm.repeat fail baseline untested test-amd64-amd64-libvirt-raw 6 xen-bootfail baseline untested test-amd64-i386-xl-qcow2 20 guest-start/debian.repeat fail baseline untested test-amd64-amd64-xl-qcow2 6 xen-bootfail baseline untested test-amd64-amd64-xl-sedf 6 xen-boot fail in 58831 like 30406 test-amd64-amd64-libvirt-xsm 6 xen-boot fail in 59576 baseline untested test-amd64-amd64-libvirt 11 guest-start fail in 59576 like 30511 test-amd64-i386-libvirt 11 guest-start fail in 59576 like 30511 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 11 guest-saverestore fail in 59961 baseline untested test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 59961 like 30394 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 60064 blocked in 30511 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 30511 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 30511 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect test-amd64-i386-xl6 xen-bootfail like 53725-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail like 58780-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail like 58786-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-bootfail like 58788-bisect test-amd64-i386-rumpuserxen-i386 6 xen-bootfail like 58799-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-bootfail like 58801-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail like 58803-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail like 58804-bisect test-amd64-i386-freebsd10-i386 6 xen-boot fail like 58805-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail like 58806-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail like 58807-bisect test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail like 58808-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-bootfail like 58809-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-boot fail like
